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TELEVISION SCHEDULE INFORMATION TRANSMISSION AND 
UTILIZATION SYSTEM AND PROCESS 

ORIGIN OF THE INVENTION 

This application is a continuation in part of copending, commonly assigned 
Young et al., Pending U.S. Patent Application Serial No. 08/198,538, filed February 
18, 1994, and entitled "User Interface for Television Schedule System," which is in 
turn a file wrapper continuing application of U.S. Patent Application Serial No. 
07/579,555, filed September 10, 1990, now abandoned. This application is further a 
continuation in part of copending, commonly assigned Roop et al., Pending U.S. 
Patent Application Serial No. 08/239,225, filed May 4, 1994 and entitled 
"Television Schedule Information Transmission and Utilization System and 
Process, " Attorney Docket STAR-005/00US. 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention : if 

The present invention relates generally to a system and method for 
broadcasting, receiving and using television schedule information. More 
particularly, it relates to such a system and : method in which the television schedule 
information is broadcast in, e.g., the vertical blanking interval (VBI) of a television 
broadcast, a schedule of television programs for a user's broadcast area or cable 
system is compiled from the broadcast, and^the schedule is displayed on the user's 
television set for interactive use. As used herein, the term "broadcast" is used in a 
broad sense to include such transmission modes as cable and telephonic transmission. 

2. Description of the Prior Art : 

It is known in the art to provide an interactive television program schedule 
system utilizing broadcast schedule information. For example, such a schedule 
system is disclosed in commonly assigned Young, U.S. Patent 4,706,121, issued 
November 10, 1987 and the above referenced Young et al. pending application. 

In the design of such a schedule system, only a limited amount of memory 
and data processing capability can be provided in the user's equipment that receives 
the schedule information broadcast, compiles the schedule for the user's broadcast 
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area or cable system, displays the schedule on the user's television set and interacts 
with the user, while enabling that equipment to be provided at a low enough price 
for mass marketing. This memory and data processing limitation was recognized by 
Hallenbeck, U.S. Patent 5,038,211, issued August 6, 1991. The solution proposed 
by Hallenbeck is to subdivide the schedule information into prioritized categories, 
store the highest priority category, and as much of the lower priority categories as 
possible in the amount of memory available. A significant problem with this 
approach is that less information may be provided about programs in the schedule 
when there are more programs in the schedule and the need for more information is 
greatest. Further development in light of the memory and processor limitations of 
consumer electronics is therefore required. 

When schedule information is transmitted as- part of a program broadcast 
signal and a prior art subscriber unit acquires the schedule information from the 
program broadcast signal, a potential problem arises when previously broadcast 
programs have been recorded on a VCR and are played back. The prior art 
subscriber unit lacks any ability to distinguish a video signal generated from a 
recorded program from a video signal received in real time from a broadcast. As a 
result, the subscriber unit may overwrite more recefit program schedule information 
acquired from a real time broadcast with older program schedule information coming 
from a video tape. 

Proposals to transmit television schedule information with television 
broadcast signals often use a low bandwidth transmission mode, such as one or more 
lines in the vertical blanking interval (VBI) of the television broadcast signals. The 
use of such low bandwidth transmission modes means that the format and 
management of the transmissions must be carefully planned in order to avoid 
practical problems. For example, when a schedule update is to be transmitted, 
unless special provisions are made for such updates, worst case transmission delay 
until the update is received and entered in a user's subscriber unit could amount to 
five hours, the time for transmission of a complete schedule for a week in an NTSC 
television broadcast signal using one line of the VBI for the schedule information. In 
the case of last minute schedule changes, such a delay would be unacceptable. 

Data encryption is essential for a subscription-based broadcast television 
schedule system. Without data encryption, the schedule information could be 
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acquired and used by pirate user equipment without payment of the subscription fee. 
However, decryption of encoded data is a processor intensive. A conventional 
approach of encrypting the entire schedule information transmission requires a faster 
and more expensive microprocessor than would ^otherwise be suitable for the 
subscriber units. 

When implementing a television schedule system on a national or even 
international basis, provision must be made for different time zones. Adjusting times - 
in the schedule for the different time zones in the process of transmitting the 
schedule adds substantial overhead to the data transmission. It would be desirable to 
eliminate the need for such adjustments in the transmission. 

It may be desirable in the operation of a television schedule system to 
provide the schedule information embedded at different places in the television signal 
at different parts of the system in order to avoid the necessity of imposing uniformity 
throughout the system. To do so, it is necessary to provide a way for recipients of 
the schedule information to identify it in the television signal. 

In the operation of a broadcast television schedule system, acquisition of new 
schedule information by the subscriber units consumes a substantial proportion of 
available microprocessor processing time. Wh&i obsolete schedule information is 
deleted and new schedule information is acquired, a substantial portion of the new 
information, such as program titles, duplicates ^formation already present in stored 
schedule information or to be deleted with the obsolete schedule information. 
Avoiding the deletion 6f information that will firm part of new schedule information 
would help to minimize the amount of processortime devoted to the acquisition of 
new schedule information. 

Because of the severe memory limitations in consumer electronic products, it 
is necessary to use the memory efficiently in order to provide as much information 
and as much functionality in the subscriber unit as possible with the available 
memory. 

SUMMARY OF THE INVENTION 

Accordingly, it is an object of this invention to provide an interactive 
television program schedule system and method that can be implemented with low 
cost microprocessors and memory in subscriber data processing systems. 
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It is another object of the invention to provide an interactive television 
program schedule system and method in which television program schedule data is 
transmitted and stored in a manner that allows a low cost microprocessor suitable for 
use in a mass produced consumer product to carry out subset searching of the 
television program schedule data. 

It is a further object of the invention to provide such a system and method in 
which television program schedule information is transmitted in an efficient manner. 

It is still another object of the invention to provide such a system and method 
in which the television program schedule information is acquired by the subscriber 
data processing systems in an efficient manner. 

It is a still further object of the invention to provide such a system and 
method in which fast schedule updates to accommodate schedule updates can be 
provided with a low bandwidth transmission system. 

It is yet another object of the invention to provide such a system and method 
that will be able to distinguish between currently broadcast schedule information and 

older schedule information included with a broadcast that was recorded. 

tt - 

It is yet a further object of the invention to provide such a system and 
method in which schedule update information is given priority treatment. 

It is another object of the invention to provide such a system and method in 
which the schedule information transmission is selectively encrypted^. 

It is a further object of the invention to provide such a system and method in 
which a single system time is employed in schedule information transmission 
portions of the system and compensation for local time is carried out in the 
subscriber units. | 

It is still another object of the invention to provide such a system and method 
in which the subscriber units are able to identify schedule information provided in 
different locations of a television broadcast signal. 

It is still another object of the invention to provide such a system and method 
in which portions of schedule information already acquired by a subscriber unit and 
which duplicate portions of new schedule information are retained, so that such 
schedule information portions need not be acquired again by the subscriber unit. 
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It is yet another object of the invention to provide such a system and method 
in which data compression is employed in a unique way to make most efficient use 
of available memory. 

The attainment of these and related objects may be achieved through use of 
the novel television schedule information transmission and utilization system and 
\ method herein disclosed. In one aspect, a television schedule information 

transmission and utilization system in accordance with this invention has a central 
data processing system. A means is connected; to the central data processing system 
for providing schedule information data for a predetermined territory to the central 
10 data processing system. The central data processing system includes means for 
formatting the schedule information data for the predetermined territory into a 
predetermined schedule information transmission format. A means is coupled to the 
central data processing system for transmitting the schedule information data for the 
predetermined territory in the predetermined schedule information transmission 
15 formats. A plurality of regional data processing systems, each located in a region of 
the predetermined territory, include means for receiving the schedule information 
data for the predetermined territory, means forselecting the schedule information 
data for the region in which each of the plurality "of regional data processing systems 
is located and means for transmitting the schedule information data for the region. A 
4: 20 plurality of subscriber data processing systenp*are in each of the regions. Each of ti- 
the plurality of subscriber data processing systems include means for receiving at 
It' least a portion of the schedule information daiaftor the region, means for storing the£ 
schedule information data received by the subscriber data processing system, means 
for assembling portions of the schedule information data received by the subscriber 
25 data processing system for display to a user of the subscriber data processing systeni 
and a display connected to the means for assembling portions of the schedule 
information data to display the portions of the schedule information data. 

In another aspect of the invention, a television schedule information 
transmission system includes a central data processing system for a predetermined 
30 territory having means for transmitting television schedule data for the predetermined 
territory and subscriber data processing systems in the predetermined territory. The 
system is improved with a plurality of regionalldata processing systems, each located 
in a region of the predetermined territory. The plurality of regional data processing 
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systems each include means for receiving the schedule information data for die 

predetermined territory, means for selecting the schedule information data for the 

region in which each of said plurality of regional data processing systems is located 

and means for transmitting the schedule information data for the region to a plurality 

of the subscriber data processing systems in each of the regions. 

In a further improvement of the television schedule transmission system, the 

means for transmitting the schedule information data for the region in each of said 

plurality of regional data processing systems has an ability to transmit the schedule 

information data for the region in different places of a television broadcast signal. 

Each of the subscriber data processing systems includes a means for locating the 

schedule information data in the television broadcast signal. 

■ ■ . ■?> . 

v In a further aspect of the invention, a method in a television schedule 

information transmission system includes transmitting schedule information data for a 
predetermined territory to a plurality of regional data processing systems each 
located in a region of the territory. The schedule information data for each region is 
selected with its regional data processing system The schedule information data for 
each region is transmitted with its regional data processing system to a plurality of 
subscriber data processing systems in each region. Portions ofttie schedule 
information data received by each subscriber data processing system are assembled 
for display to a user of each subscriber data processing system*- The portions of the 
schedule information data are displayed to the user. 

fThe method further desirably includes having at least s6me of the plurality of 
regional data processing systems transmit the schedule information data in different 
places of a television broadcast signal. Each of the plurality of subscriber data 
processing systems locates the schedule information data in the television broadcast 
signal. 

In still another aspect of the invention, a television schedule information 
transmission system includes a central data processing system for a predetermined 
territory having means for transmitting television schedule data for the predetermined 
territory and a plurality of subscriber data processing systems in the predetermined 
territory. The system is improved by providing means in the central data processing 
system for transmitting the television schedule data as commands. The commands 
include instructions for the plurality of subscriber data processing systems in the 
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system and television schedule information in elemental form used by the commands 
in the plurality of subscriber data processing systems to assemble and display a 
television schedule. 

In a still farther aspect of the invention, a method in a television schedule 
information transmission system includes transmitting commands from a central data 
processing system to a plurality of subscribed data processing systems. The 
commands include instructions for the plurality of subscriber data processing systems 
in the system and television schedule information used by the commands in the 
plurality of subscriber data processing systems to assemble and display a television 
schedule. The television schedule is assembled from the television schedule 
information in each of the plurality of subscriber data processing systems. The 
television schedule is displayed to a user of each of the plurality of subscriber data 
processing systems. 

In a still further aspect of the invention, a television schedule information 
. • " * • ....... 

transmission system includes a central data processing system for a predetermined 

territory having means for transmitting .television schedule data for the predetermined 
territory and a plurality of subscriber data processing systems in the predetermined 
territory. The system is improved with means m die cendral data processing system 
for transmitting a predetermined character string comprising a portion of the 
schedule information to the plurality of subscriber data processing systems. A means 
in each of the plurality of subscriber data processing systems determines whether the 
predetermined character string has been acquired by that subscriber data processing 
system. A means in each of the plurality of subscriber data processing systems 
stores the predetermined character string in that subscriber data processing system if 
it has not already been acquired. * 

In yet another aspect of the invention, a method in a television schedule 
information transmission system includes transmitting a predetermined character 
string comprising a portion of the schedule information to a plurality of subscriber 
data processing systems in the system. Whether the predetermined character string 
has been acquired by a particular subscriber data processing system is determined. 
The predetermined character string is stored in that subscriber data processing system 
if it has not already been acquired. 
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In a further aspect of the invention, a television schedule information 
transmission system includes a direct broadcast satellite. A central data processing 
system has means for transmitting television schedule data for the direct broadcast 
satellite to the direct broadcast satellite. Subscriber data processing systems have 
means for receiving the television schedule data for the direct broadcast satellite from 
the direct broadcast satellite. The system is improved with a plurality of regional 
data processing systems, each located in a region of a predetermined territory. The 
plurality of regional data processing systems each include means for receiving the 
schedule information data for the predetermined territory: Means selects the 
schedule information data for the region in which each of the plurality of regional 
data processing systems is located. Means transmits the schedule information data 
for the region to a plurality of the subscriber data processing systems in each of the 
regions. 1 

In another aspect of the invention, a method in a 'television schedule 
transmission system includes transmitting television schedule data for a direct 
broadcast satellite to the direct broadcast satellite. The television schedule data for 
the direct broadcast satellite is received from the direct broadcast satellite at a 
suDschbeVaat^^ 

territory js recei ved in a regional date processing system 'located in a region of the 
predetermined territory, the schedule mTFormaUo^alTftf me region in whichthe 
regional data processing system is located is selected inthe regional data processor. 
The schedule information data for the region is traromittlf to the subscriber data 
processing system. 

In still another aspect of the invention, a television schedule information 
transmission system includes a central data processing system having means for 
transmitting television schedule data. A subscriber data processing system has means 
for receiving at least some of the television schedule data transmitted by the central 
data processing system. The system is improved by providing a subscriber data 
processing system including a memory for efficiently storing database, items 
comprising the television schedule information. Each of the database items has a 
handle as an index into a handle table identifying memory locations corresponding to 
the handle. This allows physical movement of database items from one memory 
location to another for garbage collection. This allows holes in the database memory 



I 
i 



WO 95/31069 PCT/DS95/05169 

9 

which arise as data ages and is discarded tobe recovered and concatenated into large 
useful memory blocks. This trades "free" microcontroller cycles for memory, 
which is expensive. 

In a still further aspect of the invention, a method in a television schedule 
5 information transmission system includes transmitting television schedule data. At 
least some of the television schedule data isf received at a subscriber data processing 
system as database items comprising the television schedule information. Each of 
the database items has a handle. The handle is used as an index into a handle table 
identifying memory locations corresponding; to the handle. 
10 In another aspect of the invention, a television schedule information 

transmission system includes a central data processing system for a predetermined 
territory having means for transmitting television schedule data for the predetermined 
territory including updates of television schedule data previously transmitted. There 
are a plurality of subscriber data processing^ystems in the predetermined territory. 
. 15 Each of the plurality of subscriber data processing systems includes a receiver for 
television schedule data and a memory for storing television schedule data. The 
memory is coupled to the receiver. The system is improved by including means in 
the central data processing system Reassigning a transmission p^itofy for Uie 
updates of television schedule data previously transmitted relative to other television 
20 schedule data. 

In a further aspect of the invention, a method in a television schedule 
information transmission system includes establishing a relative priority for 
transmission of the television schedule information between updates of originally 
transmitted television schedule information^and originally transmitted schedule 
25 information. The television schedule information is transmitted in accordance with 
the relative priority. At least some of the transmitted television schedule information 
is received at a subscriber data processing system. 

In yet another aspect of the invention, a television schedule information 
transmission system includes a central data processing system for a predetermined 
30 territory having means for transmitting television schedule data for the predetermined 
territory and a plurality of subscriber data processing systems in the predetermined 
territory. Each of the plurality of subscriber data processing systems includes a 
receiver for television schedule data. A memory for storing television schedule data 
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is coupled to the receiver. The system is improved by including means in the central 
data processing system for identifying the transmitted television schedule data by 
time relative to other transmitted television schedule data. Means in the subscriber 
data processing system determines if television schedule data received by the 
5 subscriber data processing system has a time identification later than a time 
identification of television schedule data stored in the memory^ 

In yet a further aspect of the invention, a method in a television schedule 
transmission system includes transmitting television schedule data with an 
identification of the transmitted television schedule data by time relative to other 
10 transmitted television schedule data. The transmitted television-schedule data is 

received with a subscriber data processing system. The television schedule data is 
stored in a memory of the subscriber data processing system. Television schedule 

.* V.."' 

data is subsequently supplied including an identification by time relative to other 
television schedule data. The identification by time of the subsequently supplied 

15 television schedule data is compared with the identification by time of the television 

* K ' 

schedule data stored in the memory. The stored television schedule data is replaced 
with the subsequently supplied television schedule data if the identification by time of 

^Wsii^ 

time of the stored television schedule data. The stored television schedule data is 
20 maintained in the memory if the identification by time of the stored television 

schedule data is later than the identification by time of the subsequently supplied 

»>».■ * - 

■ ; television schedule data. / W, 

. 

In still another aspect of the invention, a television schedule information 
transmission system includes a central data processing system for a predetermined 

* 25 territory having means for transmitting television schedule data for the predetermined* 
territory and a plurality of subscriber data processing systems in the predetermined 
territory. Each of the plurality of subscriber data processing systems includes a 
receiver for television schedule data. A memory for storing television schedule data 
is coupled to the receiver. The system is improved by including means in the central 

30 data processing system for encrypting a selected portion of the television schedule 
data required by the subscriber data processing system to assemble a television 
schedule for display. Means in the subscriber data processing system decrypts the 
selected portion of the television schedule data. 
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In a still further aspect of the invention, a method in a television schedule 
transmission system includes selectively encrypting a portion of television schedule 
data necessary to assemble a television schedule for display. The television schedule 
data including the encrypted portion is transmitted. The television schedule data is 
5 received in a subscriber data processing system. The encrypted portion of the 
\ television schedule data is decrypted. The television schedule data, including the 

now decrypted portion, is used to assemble a television schedule for display. 

In another aspect of the invention, a.television schedule information 
transmission system includes a central data processing system for a predetermined 
10 territory having means for transmitting television schedule data for the predetermined 
territory and a plurality of subscriber data processing systems in the predetermined 
territory. Each of the plurality of subscriber data processing systems includes a 
receiver for television schedule data. A memory for storing television schedule data 
is coupled to the receiver. The system is improved by including a real time clock in 
15 the central data processing system for establishing a single system time for the 
, - -.<- tjcansnussipn systeip^The ipeaos.for.ti^i^ttinfcteteYisiQn schedule data jncludes . . v> 

. . ; means for transmitting the single system time. The receiver includes means for 

, receiving the single system tune. The memory has a stored value for calculating 

. local real time from the single system time.. 

20 In a further aspect of the invention, a method in a television schedule 

transmission system includes establishing a single system time related to real time. 
The single system time is transmitted to a subscriber data processing system. 



Television schedule data expressed in the single system time is transmitted^ the 
subscriber data processing system. A valuers provided to the subscriber data 

25 processing system for calculating local real time from the single system time. Local 
times are calculated for a television schedule from the schedule data expressed in the 
single system time using the value. 

In still another aspect of the invention, a television schedule information 
transmission system includes a central data processing system for a predetermined 

30 territory having means for transmitting television schedule data for the predetermined 
territory and a plurality of subscriber data processing systems in the predetermined 
territory. Each of the plurality of subscriber data processing systems includes a 
receiver for television schedule data. A memory for storing television schedule data 
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is coupled to the receiver. The system is improved by having the means for 
transmitting television schedule data configured to transmit the television schedule 
data as a show list for each day in the television schedule. The subscriber data 
processing system is configured to maintain show lists for a rolling window 
5 comprising a plurality of days extending from present time into future time. 

In a still further aspect of the invention, a method ihia television schedule 
information transmission system includes transmitting television schedule data as a 
show list for each day in the television schedule. Show lists are maintained for a 
rolling window comprising a plurality of days extending fropi present time into 
10 future time. ' ' ~ • 

In yet another aspect of the invention, a television schedule information 
transmission system includes a central data processing system for a predetermined 
territory having means for transmitting television schedule data for the predetermined 
; territory and a plurality of subscriber data processing systems in the predetermined 
15 territory. Each of said plurality of subscriber data processing systems includes a 

receiver for television schedule data. A memory for storing television schedule data 
"is coupled to the receiver. The system is improved by having the subscriber data 
processing systems configured to store the television schedule data m compressed 
form in the memory. A read only memory in the data processing system stores fixed 
20 text for the system. The fixed text is stored in said read only memory in compressed 
form. ^" ' 

f In yet a further aspect of the invention, a method inla television schedule 

information transmission system includes storing television schedule data in 

r p .... . 

compressed form in a memory of the system. Fixed text for; the system is stored in 
25 a read only memory, also in compressed form. 

The attainment of the foregoing and related objects, advantages and features 
of the invention should be more readily apparent to those skilled in the art, after 
review of the following more detailed description of the invention, taken together 
with the drawings, in which: 



30 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figures 1-5 are block diagrams of television schedule information 
transmission and utilization systems in accordance with the invention. 
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Figures 6-25 are schematic representations of message formats used in the 
systems of Figures 1-5. 

Figures 26-60 are schematic representations of data structures, flow charts 
and display formats used in the systems of Figures 1-5. 

5 

DETAILED DESCRIPTION OF THE INVENTION 

; Turning now to the drawings, more particularly to Figures 1-4, there is 
shown television schedule information transmission and utilization systems 50A-50D. 
The systems 50A-50D transmit TV schedule |data and associated network control 
10 messages as packets via the Video Blanking Interval (VBI) lines*in the TV signal 
from various television program providers 51, such as PBS, MTV or Showtime. 
~^This dataTs ; acquir^ Vst^Slght SubscrifcrUnlts 52 and used to coiratSct an 



internal diabase, this internal database cart be accessed by the Subscriber Unit 52 
to display a TV schedule for the channels that are received by the user's TV. 
. . 15 Since access to the network systems lfoA-50D is via a subscription service, 



nonsubscribers. Essentially any encryption system can be used with the invention, 
but an encryption system as disclosed in U.S. Patents 4,531,020 and 4,531,021 is 
preferred. " r ' 

. _ -20 ^tain error detection information and system overhead bytes for 

, finding the head of a packet. The information embedded in a Packet is termal a 

Z Message. Messages consist of one or more^ommands. There are varioiis types of 

^ Commands, each type distinguished by a unigue code number. Commands contain 

f * e different types of information necessary {o construct and maintain a TV schedule 

25 database, time markers, and user authorization information. 

The systems 50A-50D are data networks that deliver specially formatted data 
.to subscribers 52 located throughout the USA. This data is used to build an "on 
screen program guide" that enables the system subscribers to interactively view 
television program listings on their TV screen. The information for this network is 
30 derived from a database that is built by a computer program running on a UNIX 

computer 54. To build this database a data provider (DP) 56 is required to supply the 
computer 54 with program listing files called. Show list files. 
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Television program schedule data is generated by a vendor company at 56 
and providedto the StarSight computer center 54 in a simple interchange format. 
f Information is encoded that specifies what television programs are on at what time 

and on what channel. This data is received and processed for all channels for the 
5 entire country for 10 days. Any changes to the TV schedule are transmitted as soon 

as they are available on an as needed basis. The following description describes the J 
specific information and fields that are contained in die files. 

The Show list files are transferred electronically to the file system in 
computer 54 through a router connected to the DP's Ethernet and a digital leased line 
10 58, using the standard TCP/IP program, FTP, or other file transfer protocol standard 
mutually agreed upon. The files may require compression, due to the bulk of data 
being transferred, usmg a mutually agreed upon data compression algorithm 
compatible with the UNIX file system in computer 54. The operating speed of the 
leased line 58 will be sufficient to transfer all data files in a reasonable length of 
15 time. 

with the file transfer completed by 0800 hours PST. The daily file transfer will be 
into the home directory corresponding to the login name used to perform the file 
transfer. 

20 The "Main" file download to the computer 54 will always be for the date 12 

days into the future. Thus if today is the 10th, today's data download would be for 
start times beginning at 0000 hours GMT on the 22nd. ^ 

Since the data files are sent on a daily basis some mechanism must be in 
. place to allow for the updating of a program listing that has already been transferred. 

25 This is accomplished via the "Update" file. An Update file contains records of all 
changes that have been made since the last Update file was produced, which modify 
any of the data for any date which is still "active". An "active" date is defined as the 
dates beginning with today's date, and spanning the 11 days following (that is, all 
dates from today to the date covered by today's "Main" file, but not including that 

30 date. 

Last minute schedule changes require "Flash Updates", which provide a 
"Flash Update" file within 5 minutes after entry of any change. Such files "trickle" 
across the leased line 58 to the computer 54 throughout the day. 
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The TV schedule information is processed by the computer 54 and inserted 
into a master database. During this process, redundant information is removed. For 
example, if the I Love Lucy show is playing more than one time during the 10 days 
of schedule information, the character string for the title of that show is only stored 
5 once in the master database. For each channel and day, information is stored that 
; * specifies what shows are on at what time for the entire day. Each show may, but 

not necessarily, contain a show title and a show description. 

The purpose of the master database is to store all of the TV schedule data in 
a relational database with standardized methods to access the data. The data is 
10 organized in a way that makes retrieval of the data efficient. 

Television viewers receive a set of television video signals at the viewing 
location. Cable television providers assign broadcast and satellite program channels 
to specified channels. Every cable company has a unique assignment of channels. 
Every geographic location has a set of broadest channels that may be received in 
15 that locality. A subscriber unit must have a listing of the program channels and the 



relevant to that subscriber. 
- J 5 ^ 1 u ™?I u ^?st ?f channel a^ig^g^ti^ 

, ' Associated with each Reception Group is a region name, reception group type (cable, 

^ —r^. JfL - fe^cast^tellite), sri of zipcodrc where this set of program channels may be 

received, a list of program channels received Jand the channel assignment for those 

. • * . ■ ■ v . .,*£7 , - • #. 

program channels. V- 



The Reception Group and program channel information is referred to as a 
Line Up. Line Up information comes from njgny sources, such as commercial 

25 companies that collect the information, subscribers, cable companies and analysis of 
broadcast channel transmission coverage. 
t Line Up information obtained from a single source is not considered correct. 

Various processes are used to align data from the multiple sources to obtain one 
database with superior quality. A master database is created to which all other Line 

30 Up data is compared. Changes are made to the master database when a correction is 
verified. The primary key to associating one Line Up to another is by verifying that 
the zip code of the Line Ups are the same. Once the zip code information is 
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verified, the channel assignments are compared and verified by phone calls to the 
cable company or subscribers in the area. 

Once the TV schedule data and Reception Group data are entered into the 
master database, a computer program processes the data to emit a data stream 
5 suitable for transmission over the PBS data network. The data is compressed and 

organized optimally for the Station Nodes and subscribers 52. The specific format of 
the output data stream is described below. 

The output data stream is grouped and ordered by the data type. Due to the 
methods employed in the subscriber unit, it is optimal to sequence the data in a 
10 particular order. This allows the subscriber unit to collect an entire TV schedule in 
one pass of the data. The data blocks and their order is as follows: 

■■.v..-. >• -*e^-^- 'i- k • ti'*^ - ... :.. v ■•■ • ' ■ ■« -v.- ■ --■ 

1. Security Keys r 

Security keys are required to restrict access to the data to only those 
subscribers authorized to receive the data. Portions of the data stream are encrypted 
15 using the industry standard Data Encryption Standard security key algorithm." These 



keys may be changed at any time. To keep all of the desired subscriber units 



authorized and to change the keys, a series of messages are transmitted that contain 
the current and future security keyis. A subscriber unit's initial set of decryption A 
keys are sent in the network message that authorizes the unit to begin collecting data. 
20 The keys m this authorization message are encrypted with a key that is unique to the 
individual subscriber unit. T 

2. llieme Data ^- * 

Most of the TV programs are categorized by theme categories and sub 
categories. The master database contains a set of attributes for each* category that 
25 indicates if that TV program falls into a particular genre. Each unique combination 
of genre attributes are assigned a unique theme identification. Each show is assigned 
a theme identification based on a set of genre attributes. A table is transmitted that 
assigns a text description to each theme identification in the theme data block. 

3. Daylight Savings Time Change 

30 Data is transmitted that specifies the time when daylight savings begins and 

ends. A message is repeatedly transmitted on the data network that specifies the 
exact time that daylight savings time begins and the time that it ends. The subscriber 
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units 52 pick this message and adjust the local time to compensate for the effect of 
daylight savings. 

4. Reception Group Data 

Reception Group data contains the necessary channel line up data for all of 
5 the unique Reception Groups. This data includes Regiod ID (unique number 
\ associated with the reception group), region; type (broadcast, cable, satellite), 

Channel ID (unique number associated with the particular channel), and tune channel • 
number (channel to which the TV must be tuned to receive the channel). Any 
particular subscriber unit 52 is assigned to i Reception Group during the 
10 authorization process. The subscriber unit y/ill only process the data for the 

Reception Group for which it was authorized. All other Reception Group data is 
ignored by the subscriber unit. 

5. Channel Data 

^ Each channel reference in any recepiion group must have an associated ! 

15 channel data command. The channel data cpmmand contains information about that 
chajinel. Jf^e nativp channel ^ number i^e ^ 



broadcast channel), station call letters, network affiliation (ABC, NBC, CBS), and an 

^^fp^^--^J -^*vr -::^^^: i-^:ii*T yc^Ja.^- : ;/> - 

■ , abbreviation for the channel name; The later abbreviation is used to display a 1 to 4 

w ^ . character icon for that channel on the subscriber unit. Data for any particular J 

20 channel is only transmitted once per data cycle. 



6. Show List Data 
A show list contains a list of the TV programs and their duration for a " 

particular channel and day^ The command contains a Channel ID, start time for the 
first program, and a list of subsequent programs and their duration. Each show 
25 contains a Show lb and an optional Description ID. The Show ID and Description 
ID are each a unique number associated with the text of that show title or 
v . v desalption, respetf ^ that indicates if it isjajpay 

per view program. 

7. Show Title Data 

30 Every unique show title reference in a show list has an associated Show Title 

command. The Show Title command contains the Show ID, Theme ID, and show 
title text. Each unique Show Title is included only once in the data stream, and may 
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be used many times by the subscriber unit 52. The text in the show title is 
compressed using Huffman compression techniques. 
8. Show Description Data 

Every unique show description reference in a show list has an associated 
5 Show Description command. The Show Description command contains the Show 
Description ID, MPAA rating, critics rating, and show description text. Each 
unique Show Description is included only once in the data stream, and may be used 
many times by the subscriber unit 52. The text in the show description is 
compressed using Huffman compression techniques. 
10 9. Station Node Data Messages 

Each PBS station node receives blocks of data that will be retransmitted by 
^ " ^ in fte area ' 

serviced by the station node is'smtlo that station node. For example, the station 
node in San Francisco only receives data for the cable systerni &hd TV stations 
15 received By subscribers in the San iFrancisco fflrar'Noiie^of^l'^ Aiigeles date is 



received by the San Francisco station node. ' 

The goal of the security software for the StarSight system is provide 
cohditional access to the StarSight data stream! * Krtipni of the* data arei enciygted. " " ^ ^ 
Accdss to the schedule data is conditional in the sense that a subscriber unit 52 must 
20 know the decryption^: Only 
Key. 

v The conditional access system involves three levels of ilnoryption. At the 
top, each unit has an RSA public/private key pair. Next, batches of up to 256 units 
share a DES key, which is called the batch key. At the bottom^ program guides are 
25 encrypted with a DES key shared by all authorized units, which is called the 

program key. The program keys, changed periodically, are distributed under the 
batch keys, and the batch keys are distributed under the RSA keys, giving a three- 
level hierarchy. 

The various keys are distributed either at the factory, or in later messages as 
30 follows: 

• The RSA private key, as well as a serial number identifying the unit, are 

preprogrammed at the factory. StarSight keeps a copy of the corresponding 
RSA public key, 
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• The batch key is distributed in an authorization message, which is encrypted 
with the unit's RSA public key. The authorization message also gives the 
unit a batch number, and a unit number within the batch, a "service type" 
field, as well as the current and next program keys. The authorization 
message would typically be the first interaction between StarSight and a unit 
in die field, although it can be sent at any time to reassign batches. 

• Program keys are distributed in a key distribution message, which is 
encrypted with a batch key. The key distribution message also indicates, 
according to a unit number in the batch, whether a unit is still authorized. 
Two of the security system functions are to process the authorization and key 

distribution messages. A third function is to decrypt encrypted text with one of the 
program keysr The texHs encrypted lh cii)h^rbl^k cHinirig (CBC) mode. 

Periodicaliy, the program ]%Varec^^ the key 

" distribution messaged If a* subscriber is to Befte-authorized, they will not receive a 
new key distribution message, and willthusT)^ 

The subscriber unit 52 is a microprocessor based system designed to receive, 
process and display the TV program schedule data. The subscriber unit 52 hardware 
includes a microprocessor, read only memory? random access; memory, security co- 
processor, IR blaster co-processor, on screert18ikplay co-processor, and power" 
management circuitry. These components are combined with software that 
implements the Electronic Program Guide system. 

1. Operating System Executive f.; ■ *' " 

The microprocessor has many tasks to perform as will be described. Bach 
task must be serviced in real time, but may not necessarily be completed each time 
slice. A "round robin" executive is used to perform this function. A main loop 
sequentially calls each of the individual tasks. When a task is called, it will perform 
its defined function, based on its current state. The tasks are required to complete 
the entire task or a subtask in a pre-defined time period. This way, all of the tasks 
have an opportunity to execute their defined task within a time period. After the last 
task has executed its function, the first task is executed again. 

2. Memory Management 

Television program data is dynamic and always changing. Showlists, show 
titles, and descriptions are variable length and diange from day to day. For this 
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reason, a memory managment system is deployed that allows dynamic allocation and 
recovery of data blocks. Memory is divided into equal sized allocation blocks. The 
set of memory blocks is referred to as the pool. A handle table is created that makes 
references to the memory blocks in the pool. An application software subroutine 
5 may allocate memory by creating and storing an entry in the handle table, which 
references one or more allocation units in the memory pooh Memory may be de- 
allocated by releasing the memory references in the handle table. 

It is a requirement of the application to have continguous blocks of memory 
that exceed the length of a single memory block in the pool. This is done by 
10 allocating multiple contiguous memory blocks when needed. 

After many memory blocks are de-allocated, the memory pool will be 
fragmented. There will be many blocks of mdnoi^ 

contiguous. One of the background tasks is to de-fragment the memory pool. A 

procedure is run that moves the allocated memory blocks to the lowest possible ■ 

15 memory location. When a block of memory is moved, thereferences to that 

memory are changed in the handle table. This way the application program still has 
a reference to the memory block. Each allocation unit is moved so that any de- 
allocated blocks that are between allocated blocks are cfofiSpsed. The net result is 
that all of the de-allocated memory is at the highest possiffteinemory location and all 

20 of the blocks are contiguous. 

3. VBI Data Processing 

VBI data is decoded from the video stream and processed by an 8032 
microprocessor. A buffer is used to store the data and assemble packets. A 
comparator is used to detect a special sync character sequence. As soon as these 

25 characters are detected, the buffer is reset and the packet header is assembled. If the 
correct cyclic redundancy check (CRC) of the packet header is detected, the 
remaining portion of the packet is assembled. After the complete packet is 
assembled, an additional CRC is computed to verify that the complete packet was 
received without an error. Once this is verified, the packet is broken up and 

30 individual network messages are passed to the command processor. 

4. Command Processor 

The command processor determines if the encryptidn bit is set in the 
command header, and if so, the data is passed to the security module. The security 
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module then decrypts the data and returns it to the command processor. The 
command processor functions as a dispatcher to send the command to the correct 
processing module, based on the command function. 

5. Database Processing J 

The database processor is responsible for storing and retrieving all TV 
schedule and channel data. It receives data from the command processor and stores 
that data into the database. A set of function calls is , used to retrieve data for the - 
application program. The organization of the database is described below. 

6. Security Processing ' • 

The security processor has two major functions: key management and data 
decryption. When messages are received from the command processor that contain 
the correct serial number^or batch number^ the security processor receives the 
message and decrypts the message. In the case of an authorization message, the data 
is decrypted using the RSA private key' Tfie batch number "batch key and other 
control information is decoded and stored for future use. In the case of a key 
management message, the data is decrypted using the batch key, and the information 
is stored for future use. Program keys are distributed encrypted under the batch key. 

7. User Interface' 

The user interface takes remote control commands as its primary input. A 
user requests various functions by pressing a button on a remote control. The user 
interface receives these commands and responds with the requested $splay screen. 
In addition, display commands are generat|ff asynchronously when ^recording 
begins or when the unit attempts to collect data. 

• ^* v-:- •/ .v.. - r £~. ^ .... •' -'f^f- ■w." ' '..r- • *- 

The application has over 20 different and distinct display screens. Each 
display screen has associated with it a particular state. The data and format of the 
screen is dependent on the previous screen, the time of day, the contents of the 
database, and what remote control button was pressed. A state table is used to 
define the screen flow. 

For every defined screen, there is an entrance function, an exit function, an 
update function, and an array of key-handling functions. The entrance function is 
called when a state is first entered, to collect all necessary data and format the 

i 

T 

screen. The exit function is called to release memory and data for the screen. The 
update function is called once per minute to update the screen time and to re-draw 
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the screen if any shows have ended or any recordings have started or completed. 
Once in a particular state, the table contains a reference to another software function 
for every key on the remote control. These functions will be executed when the 
associated remote control button is pressed. 

The user interface also manages an array of pop-up windows that may appear 
and disappear on the screen either synchronously or in response to key presses. 
There are over 18 popup categories that define the screen priority for each, i.e., 
which one covers which when several popups are on the screen at once. These 
popups may be cursors, show descriptions, error messages, help messages, or 
requests for more information. Each popup category has its own entrance, exit, 
update, and key-handling routines similar to those of the main screen states. 

In addition, the user interface is responsible for iociSij| and unlocking the 
database while the user is interacting with the program guides, maintaining the 
selection and ordering of the program channels, controlling the tuner from the guide 
screens, performing the theme searches in the database, and controlling a demon that 
automatically collects schedule data at a pre-determined time from the data provider 
channel. 

8. VCR Recording ^ 

The purpose of the record manager is to maintain a Ij^of recording requests 
and to then start a recording at the correct time on the correct channel. The user 
interface defines three types of recordings, once, weekly and diaily. The user may 
record the shows he/she is currently watching or select a particular title from one of 
the guide screens. The user will move the cursor to a particular title on one of the 
guides (grid, channel or theme), press the '"record" button, and select if the program 
is to be recorded once, weekly or daily. 

Once the user confirms the recording request, an entry is made in the 
recording queue. The recording queue contains entries for each of these types of 
recordings. In the case of the daily recordings, up to five individual entries are 
made in the working record queue. A single entry is made for the weekly and once 
recordings. The working record queue represents all of the recordings that are to be 
done for the coming week sorted by show start times. 

A record demon is called from the real time executive that determines if it is 
time to start a recording. The leading entry in the working record queue is 
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examined to detemine if it is time to start that recording. If it is time, a software 
function is executed that will start the recording. Once a recording is started, the 
record demon will determine if it is time to terminate a recording. When the stop 
time is reached, a software function is executed that will terminate the recording. 
5 Starting and stopping a VCR recording is done in several ways, based on the 

• configuration of the user's equipment. In the case where a cable converter is not 

being used, the following actions are taken to start a recording: 

1. Toggle the VCR power. 

2. Tune the VCR to the desired channel. 
10 3. Put the VCR in record mode. 

If a cable converter is being used, the following actions are done: 
^ i^e^YC^^^: ^ '* — - .yr$*^-**. •'-■ ^p^ .,: *\ " ■; 

. >;..,. *. ^ ^ ne to^araiel 2, 3 or 4: ^ ^ 

3. Tune the cable con veher To the desired cfiaiinel. 
\ ' 15 4. Put the VCR in record mode. 

5. Tell the user interface software what the cur^ntly tuned channel is. 



To stop the recording, the VCR is put in stop mode and then the power is 
toggled, in all cases, these commands are performed by sending infrared commands 
to the device. _ 
20 Another function of the record demon is to examine the queue of weekly and 

daily record requests and then to spawn a new entry in the working queue. For 
example, if it is Monday morning and a daily record request is entered for a program 



in the afternoon, 5 entries will be made in the working queue, i.e. Monday, 

Tuesday, Wednesday, Thursday and Friday. After the first recording is finished on 
25 Monday afternoon, the entry in the working queue for Monday will be deleted! The 

record demon will examine the record queue and discover that it is time to add a 

new entry in the working queue for next Monday. This entry will be added in the 

time sorted order position in the working queue. 

Additionally, the demon maintains the proper start time when a daylight 
30 savings boundary is crossed. That is, the demon must add one hour to a show's start 

time in the fall and subtract one hour in the spring, provided daylight savings time is 

applicable to the user's region. 
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The record manager handles deletions, either singly or muliply depending on 
the original type of recording. 
9. On Screen Display 

An on screen display (OSD) is used to display the text and graphic 
information that makes up the various display screens. A common interface is used 
to control various devices. Three different devices can be used: the ITT TPU2740, 
the ITT CCD 3005, and the Zilog Z89300. The user interface has a set of functions 
defined to draw text, draw an embossed rectangle, draw a channel icon, and to set 
the display attributes. A set of software functions are used that translate these 
commands into the correct functions for the particular device. . 

Details of the subscriber units 52 are provided in Figure 5. The following 
description is in terms of a subscriber unit 52 fof a T^%eceive Only (TVRO) 
system (see also Figure 4). With appropriate m^ificatfohs, the subscriber unit 52 ' 
can also be incorporated in a cable decoder box for ose'with cable systems. The 
subscriber unit can also be built into televisions or VCRs or provided as a separate 
stand alone unit. 

This description is for the electronic hardware of the StarSight Telecast 
"TVRO Subscriber Unit" 52. TVRO customers are pe6pl6 who have home satellite " 
dishes for television viewing. TVRO stands for "TV ^Iceive fey". The TVRO 
Subscriber Unit 52 will hook up to the customers ^ TVrB Satellite system and will 
enable the customer to subscribe to SlarSight's Electric Prografh Guide Service. 
The TVRO Subscriber Unit 52 is a fully self contained ^separate unit, that is 
installed in series with the existing customer TVRO equipment. 

The Subscriber Unit receives ^^and^ideo from the customer TVRO 
system. The Program guide display screens are merged with the customer video in 
the Subscriber Unit. The customer has the options of Baseband Video out or 
Channel 3/4 RF out. 

The Subscriber Unit formats and displays TV program schedule information 
in real time, overlaid on top of the TV viewing screen. The TV schedule 
information is transmitted in one of the Vertical Blanking Interval (VBI) lines of a 
conventional TV broadcast. The Subscriber Unit stores this information in local on 
board memory. The information is displayed in the form of a "Grid Guide" on the 
TV screen when the customer presses a button on the remote control. 
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The Subscriber Unit 52 consists of the following sub-sections: 

• Inexpensive 8 bit Microprocessor 100. 

• 64K Bytes of code ROM 101 . 

• 512K of RAM 102 for program data storage. 

• Custom gate array 103. 

• Segmented Base Registers 104 for fast memory data manipulation. 

• Security logic 106 for decoding incoming encrypted data. 

• Serial "LM." Bus 108 for display controller interface. 

• Serial "StairSight" Bus 110 for inter processor communications. (ISB) 

• Watchdog timer 1 1 2 for error recovery. 

• IR input 113. 

c Infrared Receiver circuits 114. >A ^r * "" "" 

• Ihfraed transmitter circuits 116 for TV, VCR control. ' 

• IR output 1 IT/ . , - 5 

• CRC-32 encoding and decoding logic 118. 

• On board power supply 120. ^ - ( ' t _ 

• Power down RAM data retention 122. 

• Video Input 123. 



On Screen Display Controller arid formatter 124. 
Custom Color Converter 126 for oyerlay display. 
RF Modulator 127 * 



• Choice of Baseband Video or RF Sguits 128 or 130. ' 

The heart of the TVRO Subscriber Unit 52 is an "8032, 8 bit 
Microprocessor" 100. This microprocessor controls ail sections of the Subscriber 
Unit. A brief description of this processor will be given for reference. For more 
detail, refer to the 8032 data books from Intel or Signetics. 

The 8032 has an 8 bit Data Bus and a 16 bit Address Bus. The upper 8 bits 
of the address bus are always present. The lower 8 bits of the Address Bus are time 
multiplexed with the Data Bus and an External Address Latch is required to 
de-multiplex this bus. This latch is located inside of the DBE 1200 Gate Array 103. 
The 8032 has two address spaces, the "CODE* space and the "DATA" space. The 
DATA space is further divided into the RAM Memory area and the I/O area. 
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"CODE" refers to any access to Program ROM. The Program CODE space 
is 64K bytes long and the 8032 can only "READ" from this space. All Code access 
uses the "PSEN" (Program Store ENable) line. The -WR and -RD lines do not 
assert during CODE accesses. +ALE is the control signal used to de-multiplex the 
Address Bus. The falling edge of +ALE will latch the lower 8 bits of the address. 
-PSEN will then assert to start the ROM read. The current design has the EPROM 
-CS line always tied to ground. This makes the EPROM "OE ACCESS" time the 
determining spec for ROM reads. By today's standards, this microprocessor bus 
timing is very slow and this allows for the use of inexpensive ROMs. 

"DATA" refers to any access to external RAM 102.: Special additional 

hardware has been added to the TVRO Subscriber Unit so that the DATA area can 

,. ..... ._ ..... . ■ _ ' fcJ .- v.V 

extend past the 64K addressing limit/ this is done via segmenting "BASE 

REGISTERS" 104 and will be discussed later. The 8032 -kb strobe will assert fdr 
RAM Data Reads and the -WR strobe will assert for RAM Data Writes. PSEN will 
not assert during Data accesses. The RAM Data accesses can only take place via the 
"MOVX" instruction. No other 8032 instruction will cause -RD or -WR to assent 
Once again, +ALE is used to latch the address, then -RD or -WR will assert to start 
the data transfer. Read data must be valid just before -RD negates. The Write data 
is valid the entire time that -WR is asserted. : x " 1 

Along with the RAM Data Space, there if^ also a "^K 1/6 SPACE " . This 
VO space occupies the same first 64K segment as the DATA RAM. There is V* " 
signal called +DRAMJ3NABLE that is used to determineChich area will be ^ 
accessed. T 
The I/O space is where the system control registers are located. There are 18 write 
registers and 13 read registers. These registers are used to control the various ' 
subsystems in the Subscriber Unit. Features like clock frequency selection, serial 

bus control, I.R. status and control, etc., are all controlled through this register set. 

- ■ ^ , \ .. ... . .. . . . ( ,,.. : 

There are other control registers located in the peripheral chips. The 8032 uses two 
serial Busses to communicate and control these peripheral chips. The "IM BUS" 
108 is a 3 wire serial bus used to talk to the transaction processing unit (TPU 2740) 
124. The TPU 2740 collects the incoming VBI data and also formats and displays 
the various StarSight overlay screens. 
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The Software Serial Bus 110 is used to: talk to the Security Microprocessor 
106 and also to the IR Blaster Chip 1 16. This is a two wire bus with a unique serial 
timing protocol. 

The first 64K of 8032 Address Space fcas three separate overlapping 
functions. 

1. If -PSEN is asserted, then the CODE ROM will be accessed. 

2. If +DRAM_ENABLE = logic '0\ then dig I/O registers will be accessed. 

3. If +DRAM_ENABLE = logic T, then the first 64K of RAM will be accessed. 
The area above 64K is always RAM and the total length is 512K bytes. 

8032 SIGNAL SUMMARY ^ 

Table I summarizes the input and output signals of the 8032 microprocessor: 
Signal Name FUNCTION d Direction 

+ALE Latches the low 8 bits of the Address Bus. Output 

^-PSEN Enables Op-Code read fetches^ from ROM ~" Output 

-WR Asserts to Write to external DATA RAM Output 

-RD Asserts to Read from exten^ DATA RAM Output 

-INTO Interrupt 0-Indicates the ISB circuit requesting service. Input 

-INT1 Inte^ruptl — Indicates that pow^r is, about to fail. Inp;ut n 

PORT 0 8 bit Multiplexed 8032 Data and Address Bus. I/O 
PORT 1 Various system control bits. 1/6 
PORT 2 Upper 8 bits of the Address Bus Output 
PORT 3 8032 control bits. ; I/O 

Table! ' 

Base Register Description 

The 8032 Data Address space is only 64K bytes long. The TVRO 
Subscriber Unit however, is required to store more than 64K bytes of TV program 
data. The "READ and WRITE BASE REGISTERS w allow the 8032 to access 
additional memory above the 64K limit. 

The 8032 uses an internal 16 bit register called the "Data Pointer Register" 
(DPTR) to hold the address of the external DATA location. The Base Registers 
(located in the DBE 1200 Gate Array) hold another 16 bit value that is added to the 
Data Pointer value to form the actual RAM address. The Base Register contents is 
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shifted 4 bits left with respect to the Data Pointer so that the RAM address becomes 
20 bits long. 20 bits allows for a 1 Megabyte total Data RAM size. 
The 8032 can access any 64K byte chunk of the external RAM starting at the address 
written in the Base Registers. (Since the base register is shifted 4 bits left, the 8032 
can access any 64K byte segment starting on even 16 byte boundaries.) 
There are two base registers so that Memory Block Moves can be performed 
quickly. It would be very slow and cumbersome to the software if the value of the 
DPTR had to be changed for each read and then changed again before a write during 
block moves. The dual Base Registers allow you to put thestarting address of the 
Read (Source) Block into the Read Base Register, and the starting address of the 
Write (Destination) block into the Write Base Register. A software loop can then be 
written that does a read followed by a write to the same D£TR address. The DPTR 
is then incremented and tfie process repeated. This allows software to quickly move 
blocks "of Data any where in external HAM. ■ ■ . 

A provision has also been added to quickly disable the Base Registers. The 
signal +ENABLE_BASE will force the outputs of both Bas| Registers to all zeros. 
This is done without altering the contents of the Base Registers. This feature 
provides a quick method of accessing the first 64K segment of RAM. Both RAM 
Reads and Writes will go to the same location. Processofreiated data will be stored 
in the first 64K segment (Register Images ^Software Coun^ Values, System ' * 

Parameters etc...). The upper segments are used to store T^ program information. ^ 
Table II below tries to show how the DPTR is addeS to the Base Register to * 
form the 20 bit RAM address. 

Note: Base Reg shifted 4 bits left with * 

respect to Address bus. '•' 
Base Reg 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 

+ 8032Addr 15 14 13 12 11 10 9 8 7 65 4 32 1 0 

=20 bitAddr 19 18 17 16 15 14 13 12 11 10 9 8 17 6 54 32 1 0 
+DRAMJEN must = 1 to access the external memory area 

Table II 

As an example: 

The READ BASE REGISTER is set to 0001 Hex. 
The WRITE BASE REGISTER is set to 1080 Hex. 
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The Data Pointer (DPTR) is set to 382A Hex. 

An 8032 Read (MOVX A,@DPTR), will access address 0383A Hex (note: 20 
bits!). 

An 8032 Write (MOVX @DPTR,A), will access address 1403A Hex (note: 20 
5 bits!). 

+DRAM EN must = 0 to access the I/O area. 
DATA RAM DESCRIPTION 

As previously mentioned, the DATA RAM 102 stores the TV program guide 
information. This RAM is currently available in 3 sizes, 128K bytes, 256K bytes or 
10 512K bytes. The TVRO product uses 512K bytes. The Data RAM uses "PSRAM" 
chips. "PS" stands for Pseudo Static. The PSRAM is a standard DRAM that has 
been packaged with STATIC RAM piriouts. ^xtfa*logic is added so that DRAM 
refreshes are simplified. These PSRAMs also have a power down data retention 
feature that works down tb 3 Volts. 
r 15 There are four modes of PSRAM operation'm diis product." THey Sre: • ' " *' 



1. Sequence Up Mode. 

2. Normal Data Transfer Mode. 



^ 3. Sequence Down Mode. 

20 There are two sizds of PSRAM that can be used iri this design. The l28K by 

8 chip or the 512K by 8 chip. There is a provisiol to use two of the 128K by 8 

parts to obtain 256K bytes of total memory. v - f 

TTiese two parts have slightly different pin -outs and operate in slightly 
different methods. Circuitry has been added to compensate for these differences. 
25 There is a bit called +512KRAM that must be set l>y the software depending on 
which chip is used. 

Also the PSRAMs must go through a "Sequence Up" state after power on 
and a "Sequence Down" state just prior to power off. 
PSRAM OPERATION (Sequence Up Operation) ■ 
30 After initial power up, the PSRAMs must be "SEQUENCED UP" before any 

reads or writes can be done. The Sequence Up procedure is slightly different for 
128K and 512K parts. This procedure was added to insure that logic and timing 
specifications of the PSRAM are maintained when the PSRAMs are in the power 
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down data retention mod6. There is a provision to use a large Capacitor or a Battery 
to keep the PSRAMs powered up when the system power is lost. 
In order to preserve PSRAM data when the power is off , certain of the PSRAM 
inputs must be held in a known logic state. On top of this, these pins must follow 
defined timing constraints when they are put into the known logic states. The pins 
and logic levels are different for the 128K and the 512K parts. 
For the 128K parts: 

+Chip_Enable2 (Pin 30) and -REFRESH (Pin 1) must both be held at logic '0' 
when the power is removed to insure data retention. When going from data retention 
mode to normal operation, -REFRESH (Pin 1) must go high at -least 225nS before 
+ CHIPEN ABLE (Pin 30) goes high. 

For the 512K parts: * ^ " 

-ChipJEnable (Pin 22) must be held at logic * V and -OE/-REFRESH (Pin 24) must 
be held at logic '0* when the power is* removed to insure data retention. When going 
from data retehtidn mode to normal operation, ^hipJEnabie (Pin 22) must go high 
at least 50nS before -OE/-REFRESH (Pin 24) goes' High . 

There is also a timing constraint as to how soon after normal PSRAM 
REFRESH the above sequences can occur. The Seqi^nce Up logic in the DBE 1200 
Gate Array cdntrols the above timing; ^Ster a Power 6n*RSS (TPOR) sequence is" 
finished, the Microprocessor toggles a bit called -fSE^UENCEjUP [Wr Addr 
7400Hex, bit 5]. (Be sure to always return this bit to logic '0'). Toggling the 
+SEQUENCE_UP bit will start the Sequence Up State Machine. This State 
Machine will wait for the end of the next normal Refresh Pulse and then it will 
remove the forced logic levels using die correct timing as mentioned above. The 
refresh pulses occur about every lluS and the Sequence Up process takes about luS. 
Software should wait at least 15uS from the time that +SEQUENCE_UP is set till 
when the first PSRAM access is attempted. 
PSRAM OPERATION (Normal Operation) 

Normal PSRAM operation is very straightforward. Refreshes are automatic 
and transparent to the microprocessor. The PSRAM must be Refreshed at least once 
every 15uS. The Refresh address is generated inside the PSRAM and is transparent 
to the user. In order to do a Refresh, the Refresh pin on the PSRAM must be held 
low for a minimum time. For ease of circuit design, the Refresh Request is 



WO 95/31069 PCT/DS95/05169 

31 

generated by the internal clock divided by 256. With a 24MHz clock, this happens 
about every 10.7uS. 

The Refresh Pulse to the PSRAM chip must not occur at the same time as a 
PSRAM read or write access. Since the Refresh Request and any PSRAM access 
are asynchronous, the -PSEN line is used to start a Refresh. When the Refresh 
Request is detected, the Refresh circuit waitsluntil the next -PSEN falling edge. 
-PSEN falls at the beginning of a CODE access to ROM. CODE accesses to ROM 
happen all the time as the 8032 fetches OP-CpDES. During this time, it is 
impossible for the 8032 to access PSRAM. jhe Refresh is very fast and it will be 
finished before the -PSEN CODE fetch is complete. 

CAUTION: This system must have -PSEN toggling in order to refresh 
PSRAM. In normal operation this will happen all of the time. Be careful if you use 
an 8032 emulator. The refreshes will stop if you ever break and stop the emulator. 
Most emulators have an option to insure that .-PSEN still asserts even when an 
emulator breakpoint occurs. 

f P^^^i?N ^ (Seguenpe Dowp Pp^op) _ . _ , ■ 

Sequence Down is tfie opposite j>f Seguence Up. The system has an "Early 
yarning Power Fail ! Detector" diat will in^pipt the 8032 before |he supply voltage 
starts to drop. ThejJ032 responds to this ^^rnipt.by saving any critical PSRAM 
^^^^ s f^^ Se^uenc^Down will'force^ 

the PSRAM critical inputs to their correct stata and will do so insuring that the 
timing specification is maintained. The Sequence Down logic wilf not start until the 
end of the next Refresh to insure proper timing. The SEQUENCE DOWN rules are 
shown below. 
For the 128K parts: 

+Chip_EnabIe2 (Pin 30) must go to logic *0' at least 60nS before -REFRESH (Pin 
1) is forced to logic *0\ After the power di^, external components should hold 
these lines at logic '0' as the gate array outputs will be undefined. 
For the 512K parts: 

-ChipJEnable (Pin 22) must be forced to logic T at least 50nS before 
-OE/-REFRESH (Pin 24) is forced to logic *0\ 
PSRAM OPERATION (Power Down Data Retention) 
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As long as the critical input pins are held at their power down levels (See 
Above) and the voltage to the PSRAM chips stays above 3.0 Volts, the data will be 
retained. 

PSRAM POWER DOWN LATCH 

There is a very low current J-K Flip Flop that is powered by the same 
backup capacitor that powers the PSRAMs. This flip flop lets the software know if 
the voltage dropped below the minimum voltage specification during a power off 
period. 

At initial power on, this latch should power up to logic *0N/ The 
microprocessor can read the state of this latch on the +RAMV_OK line. If the latch 
is '0', then it should be assumed that the voltage dropped below the PSRAM 
minimum data retention specification and all RAM data is invalid! £If the latch = " 
•r, then the PSRAM data is still valid from before the power down. 

If + RAMV_OK is logic '0\ then the microprocessor can sfet it to logic T 
after self test diagnostics pass." Once this latch is set to logic 9 l\W will stay set until 
the PSRAM Vdd Voltage drops below about 3. 1 Volts. 

Five conditions are necessary to set this latch. 

1 . The PSRAM voltage must be greater than 3.1 Volts. (This rellases the J-K Flip 
Flop Reset Pin). - . , ^ 

2. The PCB +5 Volt supply must be greater than about 4.5 Volt^ (This releases 
system POR). ^ r 

3. The -ENBLAT line must be set to logic '0'. 4 

■ I:....- ,r 

4. The +BAND0 line must be set to logic T. 

5. The +LAT_CLK line must be toggled to logic *0' and theiTtoJogic *1\ 

The -ENBLAT and +LAT_CLK lines are driven by 8032 microprocessor 
PORT pins. These pins will be initialized to logic by 8032 hardware at POR 
time. The +BAND0 line comes from the DBE 1200 gate array and is reset to logic 
'0' at POR time. 

By requiring all of these conditions, it is hoped that the latch will not be able 
to be set by spurious noise glitches at power up. It would not be a bad idea to have 
checksum locations in PSRAM to verify that the data is valid if the latch reads a 
logic T. (Just in case the latch can be set by a noise glitch.) 
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The MC14xxx series CMOS devices were chosen for the latch circuit because 
this family guaranteed very low worst case current drain. 
DBE 1200 GATE ARRAY 103 

The Gate Array 103 is packaged in an 84 pin PLCC package. The Gate 
Array terminology is slightly different from the PCB terminology. The PCB uses 
" + " in front of a signal name to indicate "active high". The Gate Array dropped the 
" + " and just uses the signal name when the signal is "active high". The PCB uses 

in front of a signal name to indicate "active low". The Gate Array adds the 
letter "X" in front of a signal name when it is "active low". 

The following abbreviations for addresses and bits will be used. 
(6000W.5) = Write Address 6000 hex, bit 5. 
(6C00R.3) = Read Address 6C00 hex, bit 3. ^ 
ADDRESS DECODING 

Hie address decoders are shown on pages i ancE9 ''"of Appendix A. 74F138 type 1 of 
8 decoders are used with the 8032 -RD or -WR^trobe used for an enable The ,f "" 
outputs of ft^74F138.will be valid only when ^e proper addtess Js written or read. " „ 

The following tables show the Write and Read addresses that are decoded. 
The page number refers to the page of the GateArray schematic of Appendix A that 
the register can be found on. The "Gate Array Name" is the name of the decoded 1 
signal on die schematic. Table HI below shows the I/O Write register decodes and" 
Table IV shows the I/O read register decodes!^ 

+DRAMj5N must = 0 to access mese registeji. 4 ' 



WRITE Pg 
ADDRESS 
8032 PORT 1 X 
8032 PORT 3 X 



0000H 
0400H 
0800H 
0C00H 
1000H 
1400H 
2000H 



3 
3 
3 
3 

10 
10 
12 



WRITE 
REGISTER ACCESSED? 
VARIOUS OUTPUT CONTROL BITS 
VARIOUS CONTROL AND I/O BITS 
READ_BASE_REGISTER LOW 
READ_BASE_REGISTER HIGH 
WRITE_BASE_REGISTER_LOW 
WRITEBASEREGISTERHIGH 
PWM_CONTROL_REGISTER_LOW 
PWM_CONTROL_REGlSTER_HI 
I.M. BUS ADDRESS REGISTER 



Gate Array 
Name 



XRBASELO 

XRBASEHI 

XWBASELO 

XWBASEHI 

XPWMLO 

XPWMHI 

XL IM AD 
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2400H 


12 


2800H 


12 


2C00H 


12 


3000H 


9 


3C00H 


9 


6000H 


9 


6400H 


13 


6800H 


18 


6C00H 


29 


7000H 


24 


7400H 

■ "\ "•*.-: 
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ADDRESS 




0400H 


31 


•• • • • •> ■" 

0800H 




OCOOH 


i 6 






1000H 


12 


1400H 




1800H 


6 

■ft 


1C00H 


6 


6800H 


24 


6C00H 


29 


7000H 


16 


7400H 


16 


7800H 


17 


7C00H 


17 
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I.M. WRITE DATA 1 REGISTER XLJMDl 
I.M. WRITE DATA 2 REGISTER XL_IM_D2 
I.M. BUS START TRANSFER REGISTER XSTRT IM 
IM BUS CONTROL REGISTER XIMCTRL 
SECURITY CHIP CLOCK FREQ REGISTER XCLK_REG 

XCNTRL_1 
XWDOG_CS 
XWR_CRC 
XISBCTRL 
XISBXMIT 



OUTPUT CONTROL REGISTER 
REFRESH WATCHDOG REGISTER 
CRC-32 DATA REGISTER 
ISB CONTROL REGISTER 
ISB TRANSMIT DATA REGISTER . 
RAM SEQUENCE AND GATE ARRAY 
TEST REGISTER 
TABLE III 8032 I/O WRITE REGISTERS 

READ 

REGISTER ACCESSED 

READ TEST MULTIPLEXER REGISTER 

I.R. RECEIVE DATA REGISTER 

ISB INTERRUPT STATUS REGISTER 

I.M READ DATA BYTE # 1 _ 

I.M. READ DATA BYTE 8 2 

I.M. STATUS AND CHIP I.D. REGISTER 

I.R. RECEIVER STATUS REGISTER 

ISB RECEIVE DATA REGISTER ~ ' 

ISB STATUS REGISTER 2 

CRC-32 READ REGISTER 3 

CRC-32 READ REGISTER 2 

CRC-32 READ REGISTER 1 

CRC-32 READ REGISTER 0 



XWR TEST 

>• ... •.. ■• 



... ; .... ; ■■ 

Gate Array 
Nanie 

XRD MUX 
XIRR REG 
XRD_STAT 
XRD BYT1 
XRD BYT2 
XSW_LO 
XSW_HI 

xrIecrecj 

XISB_ST2 
XRDCRC3 
XRDCRC2 
XRDCRC1 
XRDCRCO 
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TABLE IV 8032 I/O READ REGISTERS 

PSRAM CONTROL 

The PSRAM Control logic is shown on Page 2 of Appendix A. This logic 
5 consists of simple gates that route the control signals to their proper pins depending 
. on the mode the chip is in. The chip has two memory size modes, 128K and 512K. 
There is also a Sequence Up mode and Sequence Down mode. 
PSRAM CONTROL SIGNALS 
XRFSHJ8 (-ReFreSH or address J>it_l 8) y " 
10 T This is a dual purpose signal that should Jbe tied to pin 1 of the PSRAM 

chips. When Sequenced Up, this signal is mode dependent. 
J 1 } * 28 ? mod J^ toe -J^FRESHsigi^ 

In 512K mode, Bit 18 from the Address Mux is routed to this pin. 
^1 When Sequenced Etoiwn, this signal is forced W^gic M 0 ,, V * ; * 

'l5 ' XRAM_OE0 (-RAM 6uq>ut Enable 0) " ^ ■ 
^ , ...... ... This is a dui^ purpose signal that shouldi)e tied to pin 24 of the lower 

^ PSRAM chip. When Sequenced Up, this signals mode dependent. 
^ v^> 3k- - I* 128K *WHa is the PSRAM read p^utput enable line for the lower 128K , r 
PSRAM chip. It can only assert (active low) if jhe address is to the lower 128K and 
20 , the 8032 -RD line asserts. 

... In 512K mode, this is the PSRAM read output enable AND the Refresh 

input. If this signal asserts by itself, then a reffcegh happens. If it asserts along with 
the -Chip Select pin, then a PSRAM read takes place. 
• , When Sequenced Down, this signal is forced to logic "0\ 

25 XRAM_WE0 (-RAM Write Enable 0) ; 

This signal should tie to pin 29 of the low order PSRAM chip. A PSRAM 
write will be done when this signal asserts along with a valid chip select. When 
Sequenced Up, this signal is the Write Enable to" the PSRAMs in both modes. 
When Sequenced Down, this signal is a don't care. 
30 XRAM_OEl (-RAM Output Enable 1) 

This is a dual purpose signal that should be tied to pin 24 of the upper 
PSRAM chip. When Sequenced Up, this signal is the Output Enable control for 
reads from the upper PSRAM chip in 128K mode. This signal is not used in 512K 
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mode as there is no upper chip installed. When Sequenced Down, this signal is a 
don't care. 

XRAMWE1 (-RAM Write Enable 1) 

This signal should tie to pin 29 of the high order PSRAM chip. A PSRAM 
5 write will be done when this signal asserts along with a valid chip select. When 
Sequenced Up, this signal is the Write Enable to the upper PSRAM in 128K mode. 
(Note: The current design does not use an "upper" chip in 512K mode.) When 
Sequenced Down, this signal is a don't care. 

XCE1 (-Chip Enable 1) - 

10 This is "a dual purpose signal that should be tied to pin 22 of the PSRAM 

chips. When Sequenced Up, this signal enables the PSRAM chips to read and write 
in both modes. When SequencS'bown^this^sTgnalls^for^ to logic' "I"'. The 
512K PSRAM chip requires this line to be forced to logic H " during power down 

data retention mode. This line is a don't care on 128K PSRAMs. 

15 CE2f A17 * (+Chip Enabled or Addresslbirl?) " ' ^ 

* This is a dual purpose signal that should be tied ttf pin 30 of the PSRAM 
chips. When Sequenced Up, this signal is mode dependent. 

In 128K mode, this signal is tied to +Chip Eriable'and it is always logic "1". 
In 512K mode, Bit 17 from the Address Mux is routed to this pin. 
20 XWFLSTROB (-WRite STROBey" " - ^ X : 

During write, this is a shorter version of the 8032%rite strobe. 
XWRSTROB is the timing signal used to write to PSRAMS. Data is written to 
PSRAM at the rising edge of XWRSTROB. This rising fedge hits before the rising 
x ~" edge of the '8032* -WR to 'insure that any PS&^data^ met/ *' " 

25 BASE REGISTERS AND 

Pages 3 and 4 of the Gate Array schematics in Appendix A show the Base 
Registers and the PSRAM address Multiplexer. See above for a description of the 
Base Register functions. This section will deal with the circuitry, 

the Base Registers are shown at the left of Page 2. The outputs of these 
30 registers pass through "AND" gates before going into the Adders. The AND gates 
allow the base register outputs to be quickly forced to all zeros at the Adder inputs. 

The outputs of the Adders feed over to the MUX. This MUX places the 
results of the READ ADDERS on the PSRAM address pins most of the time by 
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default. There is no way to know that the 8032 is going to do a write until the -WR 
strobe asserts. When -WR asserts, a flip flop switches the MUX over to the WRITE 
ADDER output. The read adder was chosen for the default value because RAM 
reads take a little longer than writes. The diial adders are there so that the write 
address is stable as soon as the -WR strobe asserts. 

1. R. RECEIVE CIRCUIT 

The I.R. Receive circuit has various modes of operation depending on 
whether die button on the remote is released or if it is continuously held down. This 
circuit is on page 5 of Appendix A. 

When a valid code is clocked into the I.R. RECEIVE DATA REGISTER 
(0800R), the +IRRJVAL (IR Receive Valid^ bit and the + VALTILRD (VALid 
TIL RD) bits will set. The +IRR VAL bit^will remain set until the remote button 
is released. There are 2 ways to clear the +VALTDLRD bit. 

i; Reading the I.R. RECEIVE DATA RE(SSTER will clear + VALTILRD. 

...... =* ' . . : , . •• .»w/r: ... / ■ . T . ->■ -; - . : 

2. If the remote button is released and then pressed again, then + VALTILRD will 

clear when the button is re-pressed. 

+IRR_NC (I.R. RECEIVER NO CHANGE) will set the first time that the 
I.R. RECEIVE DATA REGISTER is read.^jft will ^remain set until the remote 
button is released. "\" 

+IRRRDY goes high as soon as the remote button is pressed and stays set 
until released. 

:• • vjei ■•■ 

SECURITY CLOCK GENERATOR ' 7 - 

The Security Clock Generator is at th£ lower middle of page 9 in Appendix 
A. This is a programmable clock generator Jbr, die Motorola Security Chip. The 
original spec for this clock was 5 MHz. To gilow for changing oscillator 
frequencies, this clock was made programmable. 

Both the high time and the low time qf this clock period can be programmed 
independently by writing to I/O address 3C00hex. The high time is set with the 
upper nibble while the lower nibble sets the low time. This time is in multiples of 
the input oscillator frequency. 

The circuit works by loading the program nibbles into 74F169 type counters. 
These counters are set up as "down counters" and only one of them will decrement 
at any one time. After one counter reaches ziero, the output will toggle, the counter 
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will re-load and then the other counter will decrement. The inverters at the output of 
the program register set the initial value to "divide-by-7". 
I.M. SERIAL BUS CIRCUIT 

The I.M. Bus is used to talk to the TPU 2740 chip. The LM. bus circuit i§ shown 
in Figures. Refer to the I.M. bus specification for a detailed explanation of this bus. 
Briefly, the I.M. bus is a 3 wire serial communication bus. The 3 lines are called 
LM._CLOCK, LM._DATA and LM._IDENTIFY. The DBE 1200 gate array is 
always the I.M. Bus Master and therefore always drives the I.M._CLOCK line. The 
I.M._DATA line is a bi-directional data line (Open Drain with an external pull up 
resistor). The LM. JDENTIFY line is an output used tp identify the "I.M. Address" 
and also to terminate the transfer. An "IM BUS WRITE" is a transfer out of the 
8032 to the IM Slave. An "IM BUS READ" is into theJiQ32 from the IM Slave 
device. 

I.M. bus transfers always start with a 1 byte adcfress and then 1 or 2 bytes of 
data.. A bit called IIBYTE (3000W.0) determines how many data bytes to transfer. 
Another bit called WXRBIT (3000W.1) determines if ttit transfer will be a read or 
a write. Page 11 of Appendix A shows the LM. counter and control logic and Page 
12 shows the I.M. Data Shift Registers. 
I.M. CIRCUIT OVERVIEW * 

The LM. circuit is operated via the control and (lata registers. Here is a 
quick summary: 

LM. BUS ADDRESS REGISTER (2000W pagefl2 XL IM AD) . The 
8032 writes the 8 bit address of the slave device that communication should be 
established with here. This address is latched in the 74HCT273 in Figure and is 
transferred to the shift register when the transfer begins^ It is not necessary to reload 
this register if the same address is accessed on two successive LM. transfers. The 
byte written to this register will always be the first byte written out of the Gate 
Array for all I.M. transfers. 

LM. WRITE DATA 1 REGISTER (2400W page 12 XLJMJM) . The 
byte contained in this register will be the 2nd byte shifted out onto the I.M. bus 
during LM. Writes. This register must be reloaded after each transfer. 

LM. WRITE DATA 2 REGISTER (2800W page 12 XL IM_D2) . The 
byte contained in this register will be the 3rd byte shifted out during I.M. Writes, 
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but only if the transfer length is set to 2 bytes. This register must be reloaded after 
each transfer. 

LM. READ DATA BYTE 1 (1000R page 12 XRDJBYTl) . After a read 
transfer, this register will contain the incoming data byte. If it is a 1 byte read 
transfer, then the data will be in this register. If it is a 2 byte read transfer, then the 
second byte received will be in this register. 

LM. READ DATA BYTE 2 (1400R page 12 XRD_BYT2) . After a 2 
byte read transfer, this register will contain the first incoming data byte. During a 1 
byte read transfer, the outgoing address will^wrap back and end up in this register. 
This wrap feature can be used for error chegking or diagnostics. .;. 

I.M. BUS CONTROL REGISTER. (3000W page 9 XIM_CTRL) 
: Bit 1 of this register determines whether thi^^fer is read or write. -Bit 0 of this 
register determines if 1 or 2 data bytes will be transferred. 

LM. BUS START TRANSFER RE^IJSTER. (2C00W page y 
^J&TJM) Writing any value to this register will start the LM. bus hardware, 

LM. BUS STATUS AGISTER. (1 800R page 6 J^JJp) Bit 7 of this 
register contains the +IM_BUSY line. This line will be high during the LM. 
transfer. 

lm. cmcurr OPERATION _ / _ J 

The logic on page 11 controls the LM. Bus4ransfers. 5 The LM. r clpcJc JffMJPjCK) 
and the 8032 input oscillator elk (OSC_2) are both derived from the 24MHz 
oscillator. The 8032 does not specify any timing with respect to the input oscillator 
and^ the timing that is specified is very Icose^wjth respect to a. 12MHz input clock. 
j!? r * is r f?? OI1 » £ 5WSt be assumed th$ Jie|tart Transfer ^Pulse frpm^tiie 8032 an0 
the IM_P_CK are asynchronous. The first 3 flip flops at the lower left of Figure are 
used to re-synchronize these signals and to start the LM. transfer. 

After the transfer is started, the 74F269 counter on page 1 1 will start to 
count up from zero. The ENIMCK line win allow the IMP_CK to gate out to the 
LM. bus clock pin 14. The first 8 clocks will clock out the address and the 
I.M.JDENTIFY line will assert during this time. When the counter reaches a count 
of 8, the I.M.JDENTIFY line will negate. 

If an LM. Write is in progress, then the LM._DATA line will continue to be 
an output for the rest of the transfer. If an LM. Read is in progress, the 
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I.M._DATA line will switch from an output to an input after the 8th count. The 
transfer will abort after count 16 or count 24 depending on the state of the II BYTE 
(3C00W.0) bit. 

After all of the clocks have completed, the I.M. JTOENTIFY line will briefly 
5 pulse low one more time to indicate that the transfer is complete. During this entire 
time, the IMJBUS Y bit will be asserted and available to the 8032 as status. The 
IM_P_CLK is created by dividing the 24MHz oscillator by 32. This yields a clock 
edge at about every 1.3 uS. A full 24 clock transfer takes about 32 uS. 
WATCHDOG TIMER 

10 : The Watchdog Timer is on page 13 of the Gate Array Schematic, Appendix A. This 
timer can be turned on and off with the bit EN_WDOG (3000W.7). The Watchdog 
is reset in normal operation by writing to address 6400W. Theudata written to this 
address is "don't care". 



The Watchdog timer is 16 bits long and it is clocked by the OSC 256 clock. 
15 This timer was made out of synchronous counter blocks (IJSCBR) provided by the 
Gate Array vendor. The Watchdog starts at Zero and counts lip. If it is allowed to 
overflow, then the reset line to the 8032 will assert. The Power on Reset line to the 
Gate Array will also assert. The 8032 reset line will assert about 256 clocks before 
the Gate Array POR internal reset asserts. The 8032 requires that a fixed number of 
20 clocks be provided while the reset line is asserted in order to p^perly reset. The 
internal Gate Array POR line completely resets the Watchdog circuit, so it is 
necessary to delay these events for prdper 8032 reset timing. 



NOTE: The Gate Array internal POR line completely resets the chip to a known 



state except for the OSC divider clocks on page 9 and the IM Read data registers on 
25 page 12. 

CRC 32 POLYNOMIAL CIRCUIT 

The CRC-32 circuit is on pages 15-18 of the Gate Array Schematic. This 
circuit can be used to Check or Generate the CRC-32 Polynomial. This polynomial 
is four bytes long and is used to verify data integrity. 
30 The circuit has two modes of operation, CRC-32 on and CRC-32 off. The 

bit X_EN_XOR (6000W.4) determines the mode. When this bit is logic n 0\ the 
CRC-32 logic is enabled and any data written to the CRC registers will be multiplied 
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by the CRC-32 polynomial. When this bit is logic "1\ the CRC-32 polynomial is 
disabled and the data shifts into the CRC-32 registers unaltered. 

The circuit consists of four 8 bit Read Data Registers, one Write Data 
Register, the above mentioned control bit and control logic. Here is a summary of 
the registers. 

CRC-32 READ REGISTER 3 
CRC-32 READ REGISTER 2 
CRC-32 READ REGISTER 1 
CRC-32 READ REGISTER 0 
CRC-32 WRITE DATA REGISTER (6800W) ^ 
XJENXOR Control bit (6000W.4) 
CRC 32 CIRCUIT OPERATION 

Data is entered into the CRC circuit one byte at a time. This is done by 
writing* the byte to the CRC-32 Write Data Regisj|r (6800W). After the 8032 "I \ 
completes the write, a Iwdware state marine wllj take the byte and shift it into tjie. 
CRC circuit. (This shjft t takes a^out 1 ^uS jf tfeejDSiC is 24NJHz,) , When £11 of 
the bytes have been shifted in, the resultant can be read out of the four CRC-32 Read 
Registers. The CRC circuit can be turned off u^jrder to initialize the four regteters 
to a known value. 

The CRC-32 Write Data Register is on gaje 18. This is a parallel in, serial 
out shift register. The end of the 8032 -WR strode will start the shift logic in p?ge 
15. This lo]gic will synchronize the shift start to the OSC 2 clock. A 3 bit counter 
will count out exactly 8 clocks, then shut the circuit off. 

The XJENXOR bit can beused to initiaiije the CRC-32 circuit to a known 
value. Some CRC schemes start with all 32 bits set zero, others start with all bits 
set to one. When X_EN_XOR is set to logic T, the CRC-32 circuit Exclusive-OR 
*^J™£1. <cli ?2 ble ^; ^"nw? allows the data witte^ tp ^ , 
Register to enter the CRC-32 flip flop chain unaltered. This feature also allows for 
breaks in the CRC calculation. When a break occurs, the software could read and 
store the data in the four CRC-32 READ REGISTERS. At a later time, this data 
can then be reloaded back into these registers. 
The CRC-32 polynomial is: 



(7000R) 
(7400R) 
(7800R) 
(7C00R) 
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x*32+x A 26+x*23+x~22+x A 16+x"12+x A ll+x A 10+x A 8+x~7+x A 5+x A 4+x"2+ 
x+1. 

GATE ARRAY PINOUTS 

Table V shows the pinouts for the gate array 
PIN NAME PIN TYPE SPECIAL NOTES 



PIN 
NO. 
I 
2 
3 
4 
5 

6 
7 

9 

io 
n 
12 

w 

14 

ts 

16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 



GND1 

VDD1 

PRAM_A15 

PRAM.A16 

PXRFSH18 

..J - 

PTESTOUT 

PBAND1 

PBANDO 

PIRR_DTA 

PIRR_CLK 

PIRR_RDY 

PJXRESET 

P_IM_DTA 

PIM_CLK 

PIM IDEN 



POWER 

POWER 

OUTPUT2 

OUTPUT_2 

OUTPUT_2 

OUTPUT_2 

OUTPUT1 

OUTPUTJ 

INPUTJ 

INPUT_1 

INPIJT_1 

INPUTJ 

I/O J 

OUTPUT_4 
OUTPUT 4 



PXRAMWE1 OUTPUTJ 
PXRAMWEO OUTPUT_3 
PRAM A13 OUTPUT 2 



PRAM_A8 

PRAM_A6 

PRAM_A9 

GND2 

VDD2 

PRAMA5 

PRAM_A11 

PRAM A4 



OUTPUTJ 

OUTPUT_2 

OUTPUTJ 

POWER 

POWER 

OUTPUTJ 

OUTPUT_2 

OUTPUT 2 



drives psram address line 
drives psram address line . 
drives psram rfsh in 128K mode, A18 in 512K 
mode. 

TEST OUTPUT 
output digital control bit. 
output digital control bit. 
IR input 
IR input 
IR input 



SYSTEM POWER ON RESET 
IM bus data line, open drain 

' • • : > yv. 

IM bus elk line, output only 
IM bus identify line 
PSRAM #1 R/W line 
PSI^ #0 R/W line 
drives psram address line 
drives psram address line 
drives psram address line 
drives psram address line 



drives psram address line 
drives psram address line 
drives psram address line 
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28 












Ju 




< 








32 






33 


-'. 






J 




jj 




10 


1A 


>•' 










J / 


; ■ >'-? 


* r" 








JO 




r ■ . •••• - • 


39 






40 






41 












43 




• w - . v 






. . • . »■ 


44 






45 


■* •Vt 


20 


46 


> VVv ' 










47 












48 


* 

" } '\ '■ i 




49 






CA 

50 


v.- 


25 


51 






52 






53 




-~ 


D4 






55 




30 


56 


\ 










57 






58 






59 



PRAMA10 

PXRAMOE0 

PXRAMOE1 

PXCE1 

P6805CLK 

POSC_2 

P_XWR 

PXRD 

PXISBINT 

PUPRESET 

PDRAMEN 

PXENBASE 

P_AD0 

P_AD1 . 

P_AD2 . 

P_AD3 

GND3 

VDD3 

P_AD4 

P _AD5 

P AD6 

P_AD7 

P_ALE 

P XPSEN 

P_A15 

P_A14 

P_A13 

P_A12 

P_A11 

P_A10 

P_A9 

P_A8 

PIR XCLK 



OUTPUT 2 

OUTPUT3 

OUTPUT_3 

OUTPUT_3 

OUTPUT4 

OUTPyT_4 

INPUT_1 

INPUT1 

OUTPUT3 

OUTPUT3 

INPUT2 

INPUT2 

I/0_2 

I/0_2 

VO_2 

I/Q_2 

POWER 

POWER 

I/0_2 

I/0_2 

I/0_2 

I/0_2 

INPUT1 

INPUTJ 

INPUT2 

INPUT2 

INPUT 2 

INPUT_2 

INPUT_2 

INPUT_2 

INPUT2 

INPUT2 

OUTPUT 4 



43 

drives psram address line 

PSRAM #0 output enable line 

PSRAM #1 output enable line 

PSRAM chip select 

Security Micro Clock 

8Q32|microprocessor clock _ 

8032 write strobe 

8032- read strobe 

ISB interrupt line to 8032 

active high reset to 8032 . 

RAM enable bit 

Base Register enable bit 

8032'data bus 

8032|data bus _ 

8032^dam bus 

* *«' ' i^r.:-.:- 

#m bus ........ 



8032^data bus 

' 

8032£data bus 
803^jdata bus 
803iaatabus 
8032 address latch enable 

1 8p32^rpgram store , enable 
8032 ^upper address bus bit 
8032 upper address bus bit 
8032 upper address bus bit 
8032 upper address bus bit 
8032 ypper address bus bit 
8032 upper address bus bit 
8032 upper address bus bit 
8032 upper address bus bit 

2 or 4 MHz elk for IR transmitter 



J? 

r 
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60 


P_A0 


61 


It A 1 

P_A1 




P_A2 


63 


P_A3 


CA 

64 


GND4 


65 


VDD4 


cc 
66 


TW»f ATI 

PXTAL1 


67 


PXTAL2 


68 


T» A A 

P_A4 


69 


P_A5 


70 


P_A6 


71 


PA7 


72 


PISBCLK 


73 . 


PISB_DTA 


74 ' 


PBAND2 


75 ~' 


PI378_IN 


76 


P13780UT 



demultiplexed 8032 lower address bus bit 
demultiplexed 8032 lower address bus bit 
demultiplexed 8032 lower address bus bit 
demultiplexed 8032 lower address bus bit 



77 
78 
79 
80 
81 
82 
83 



OUTPUT3 
OUTPUTJ 
OUTPUT3 
OUTPUT_3 
I/OJ 
I/0_1 

OUTPUTJ 
INPUT J 
OUTPUT4 
PPWM OUf OUTPUT_4 
PRFSEL2 OUTPUT _ 
PRF_SEL1 OUTPUTJ 
PRFSEL0 OUTPUTJ 
PRAM_A7 OUTPUT_2 
PRAM_A12 OUTPUT2 
PCE2 A17 OUTPUT 2 



OUTPUTJ 
OUTPUTJ 
OUTPUTJ 
OUTPUTJ 
POWER 
POWER 

OSC INPUT external crystal oscillator pin 
OSC OUT external crystal oscillator pin 

demultiplexed 8032 lower address bus bit 
demultiplexed 8032 lower -address bus bit 
demultiplexed 8032 lower address bus bit 



demultiplexed 8032 lower address bus bit 
ISB elk line •*'* 



I- 



84 PRAM A14 OUTPUT 2 



ISB data line 

output digital control bit. 

divide by 2275 elk input fonMC1378 

divide by 2275 output for MCI 378 

Pulse Width Modulator output 

output digital control bit. 

output digital control bit. ~ . 

output digital control bit. 
• , 
drives psram address line r 

drives psram address line 

PSRAM CE2 in 128K mode, A17 in 512K 

mode 

drives psram address line 



OUTPUTJ = 4mA, NORMAL SPEED, (OUTPUT PORT CONTROL BITS) 
OUTPUT_2 = 2mA„ SLOW (lOnS) RISE AND FALL TIMES (PSRAM 
ADDRESS OUTPUTS) 

OUTPUT_3 = 2mA NORMAL SPEED OUTPUT. 
OUTPUT_4 = 4mA NORMAL SPEED OUTPUT. (Used for CLOCKS). 
Note: Outputs 1 and 2 grouped differently so output bit current can easily be 
changed between groups. 
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INPUT1 = TTL INPUT LEVELS WITH SCHMITT TRIGGER . 
INPUT 2 = TTL INPUT LEVELS. 

I/0_1 = 2mA OUTPUT DRIVER (with active high enable) , OPEN DRAIN OR 
TRISTATABLE. INPUT IS TTL LEVEL ] 

I/0_2 = 2mA OUTPUT DRIVER (with active high enable). INPUT IS TTL 
LEVEL [date bus] ; j. 

Table V 

TPU 2740 ONSCREEN CONTROLLER 124 

The TPU 2740 124 functions as an Op Screen Display (OSD) controller and 
also as a Closed Caption Data (CCD) VBI D$ta Slicer. This device has two 
functionally separate sections, the OSD and the CCD VBI data slicer. The TPU 
2740 contains a RISC based processor calle^ithe Fast Processor (FP) that is used to 
collect the VBI data, communicate with the serial bus, and control the OSD. Some 
of the internal TPU2740 circuits are running St four times the input clock frequency 
(This is 72MHz on the TVRO board wi^ c ah48MHz input clqck). ... Communications . 
between the 8032 and the TPU2740 are via die 3 wire IM Serial Bus 108 

The TPU 2740 is a fully digital chip, Baseband Video data must first be 
digitized before the TPU can use it. A j^bj^Ai^ofe tq Digital converter (uPQ660) 
does this digitizing. 

., The uPC660 is shown on page 1 of th^TVIto schematics in Appendix^A. 
The input video signal is about 1 Volt P-P and this signal must be "clamped"^ tp. a 
known DC level before it can be digitized, |he "VIDEO CLAMP AND FILTER" 
on page 1 does this using a "Back Porch Clamp* method. This clamp will bias the 
video signal into the A/D converter so that die "Back Porch" area will be at about 
3.69 Volts DC. (The "Back Porch" is the area where the color burst sits.) 

The resistor network on page 1 comprised of R15, R16, R17 and R18 sets 
the voltage levels for the clamp and the A/D circuits. The A/D upper reference 
(pinll) is set to about 4.52 Volts and the lower.reference (pin 13) is set to about 
3.35 Volts. If the input video signal back porch area is biased to 3.69 Volts DC (at 
pin 12), then the maximum peak to peak swing of the video signal should always be 
between the voltages at the reference pins. The TPU only uses the incoming video 
signal to strip off VBI Closed Caption Data. There is no need for the entire 4MHz 
video bandwidth so R7 and C6 form a low pass filter that rolls off the TPU video at 
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about 1MHz. (Note: The ratios of the clamp voltages are the same as the expected 
video signal IRE values.) 

Circuitry in the TPU detects vertical and horizontal sync from the digitized 
video. The OSD and VBI data slicers use these signals for;timing functions. A 
5 programmable comparator is used to detect vertical and horizontal sync pulses. It is 
important that the video clamp function correctly in order for this comparator to 
accurately detect sync. The FP reads the output of the sync detection circuitry and is . 
able to count horizontal lines, thus is able to read VBI data from a particular VBI 
line and start the graphic on screen display at the correct video scan line. When a 
10 VBI signal that contains the proper lead in and framing data is detected, the VBI 
circuitry on the TPU will load the VBI data into internal registers that the FP may 
read. The FP reads this data and inserts it into a buffer. At a later time the VBI 
data may be read by the 8032 via the IM Bus. 

The TPU requires good digitized video and a stat>ie;'horizorital timing 

- -> ' ■-■ . . *; . . .- . ( . ..... ■ . U;.J- • • ->•• 

15 reference on pin 27. The horizontal rate signal is +Burst Gate from the MC1378 

and is fed into the TPU at pin 27. If either of these sigral|js missing or poor, then 

the TPU will not be able to create a stable overlay. 
^ The OSD portion of the TPU consists of cache memory, character memory, 

timing functions, and an external 256K by 4 bit DRAM (U9). The FP reads high 
20 , level graphic commands from the IM Bus and stores the graphic information in the 

external DRAM memory. In conjunction with the cache memory, timing circuitry, 
j and the character generation hardware, the TPU FP outputiffie gr^)hic data on the 

R, G, B, and FBLOUT lines. 8 colors may be generated uSing the R, G, and B 

outputs. The FBLOUT (Fast BLanking OUT) signal determines if the video output 
25 should contain the R, G, B data from the TPU, or if the incoming live video should 

be passed through. 

The TPU has a 256K x 4 DRAM (U9) for storing overlay screens and data. 
This is a fast page mode DRAM and refresh logic is avoided by constantly reading 
out the screen data, even when there is no overlay on the screen. 
30 R,G,B COLOR CONVERTER. 

The StarSight Telecast graphic display requires 8 colors, black, white, gray, 
yellow, light yellow, light green, and red. These colors ar6 not the standard 8 
NTSC saturated colors that the TPU puts out. A "Color Converter Circuit" is 
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required to translate the TPU saturated digital colors into the StarSight graphic 
display "pleasing" colors. This circuit is on page 2 of the PCB schematic. 
The Color Converter if made from three "8 into 1 analog switches". There is one 
switch for each of the R,G,B outputs. There is ft precision voltage divider that 
creates the desired R,G,B voltages. The analog switches route the proper voltage to 
. their outputs based on the 3 bit digital R,G,B signal from the TPU. The TPU 
R,G,B outputs are programmed to be open drairi so that a full TTL level swing is • 
available to the multiplexing analog switches. R14 and C18 on page 2 form an 
inexpensive R-C delay for the Fast Blanking Signal to compensate for delays in the 
R,G,B channel. ir • 

OVERLAY GENERATOR AND VIDEO SYNCHRONIZER. 

The Motorola MC 1378 is used as a mai| building block for the Video 
Synchronizer. The MC1378 operates in REMOTE MODE (pin 1 is set HIGH). In 
this mode, external video is required to create flie f synchronizing timing signals. See 
page 3 of the TVRO Schematic of Appendix A for a block diagram of the 1378. 

A l.yplt peak to peak, NTSC. video sigi^l must be fed into pin 24 to provide 
timing information for both the 1378 and the TPU. 

The signal at pin 24 is called the •^mojejyideo Signal; ... This,signal is 
internally claipped in the 1378 and then Comjjp^te sync is separated out. Composite 
Sync is used to separate out Vertical Sync and also to lock thqjM)3 MHz Horizontal 
Phase Locked Loop. Both Composite Sync (phj_39) and Vertical Sync (pin 38) are 
externally available for debug and timing. * f i : 

The separated composite sync is used to jock the 4.03 MHz PLL (using 
PD1). The VCO in this PLL is formed around^ 4.03MHz ceramic resonator. The 
free running frequency of this ceramic resonato|must be adjusted with C39. The 
best way to adjust this VCO is to use a frequency counter and adjust C39 until the 
frequency at Ul-5 is 15,750 Hz., This adjustment is made with the Video In signal 
disconnected so that the VCO is free running. , 

The 4,03 MHz VCO output is divided by 256 to obtain horizontal frequency, 
and then further decoded to create "BURST GATE". Burst Gate (MC1378 pin 5) is 
about 4uS wide and is centered around the 3.58MHz color burst. This signal is the 
main timing reference for the overlay display. 1J is used extensively by both the 
1378 and TPU 2740. The TPU uses Burst Gate to decide when to start the overlay. 
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There is a programmable counter in the TPU that sets the delay from Burst Gate to 
the overlay start. (The overlay starts when +FBLOUT goes low.) Any jitter on 
Burst Gate will cause an annoying side to side motion on the overlay. 

The color burst from the remote video is used to lock; the 4X color sub 
carrier oscillator using PD3 which is gated by burst gate. 

Phase of the locally generated composite video from the encoder section is 
compared against the same sub carrier reference used to lock PD3. This is done by 
means of PD4 so that the sub carrier phases of both the local and the remote signals 
are made essentially equal. 
Phase detector operation summary: 

1. PD1 - compares and locks the internally counted down 4.03 MHz VCO to 
the incoming remote horizontal sync. It is fast acting to follow VCR source 
fluctuation. Its PLL filter network consists of C24, C38, ami R19. 

2. PD2 - is not used in this design. " 

3. PD3 - a gated phase detector, which locks the ci^staf oscillator frequency 
divided by four to the incoming remote signal burst. 

4. PD4 - controls the internal phase shifter to assure that the outgoing local 

color burst has the same phase as the incoming remote burst at PD3. 

- ■ •• - . - . ■ ■■■■■■ * I.-] ■ / '■ - .-'"■-"* 

5. PD5 - not used in this mode of operation 

Video paths inside the MC1378 

The remote video is AC coupled and fed in through pin 24 and clamped to 
proper DC level (blanking is at 0 V). The clamped video i^fed to the Fast Video 1 
Switch where switching between the local and the remote video occurs controlled by 
Overlay Enable at pin 25. The second path leads to the PD3 where the remote video 
burst is compared against crystal oscillator frequency divide^ by four. The third 
path leads to Identity Detector which determines whether incoming signal is PAL or 
NTSC. 

The local video is generated from R, G, and B signals which are direct 
coupled, 1 volt peak to peak inputs at pins 14, 15, and 16. After that follows the 
Color Difference and Luma Matrix which produces B-Y, R-Y, and the luminance -Y 
signals. The B-Y and R-Y signals are clamped and sent to their respective 
modulators. Modulated B-Y and R-Y signals are summed together thus making 3.58 
MHz NTSC chroma signal which is fed out pin 18. This chroma signal is filtered 



WO 95/31069 PCT/US95/05169 

49 

by a 3.58 MHz band-pass filter consisting of C33, C34, C35, R22, R13, and Tl. 
The filtered chroma signal is fed back in at pin 20. At this point the chroma signal 
is added to the luminance signal which passes through a 400 nS delay line. The need 
for this delay line arises because of the longer path for the chroma signal through the 
modulators and the band-pass filter. The delay line should have at least 4 MHz 
bandwidth, and good linearity through its Entire bandwidth as well as linear group 
delay. Tlie chroma and luma signals combined make the composite NTSC video 
signal which is then clamped by the local video clamp and fed to the fast video 
switch to be mixed with the remote video at the output pin 27. 

To keep the local video ainpliftujp gorrect in respect to the remote video 
amplitude the two burst amplitudes are compared in the ACC detector and made 
eqiudusing^a variable gain AOC^ 

The absolute burst amplitude of the remote signal is detected by the kill 
detector, the chroma of the locally generat&i signal being turned off when the remote 
burst falls below a predetermined level. The kill level can be adjusted byj changing 
the value of the resistor R3 at pin 31. 47J3K kills at about 10-20 mVp : p remote 
burst. Normal burst is 286 mVp^). 
POWER SUPPLY v 

The system requires 5 VDC digital^ SVDC analog, and possibly 12 VDC 
analog (for certain RF Modulators). ^ 
The current requirements are: 

5 VDC Digital 550mA - * 

5 VDC Analog 150mA . 

12 VDC Analog 80mA ^_;"*' : * 

It is very important that the microprocessor -PWRBAD line is seuto zero at 
least lOmS before the 5 VDC Digital supply drops below 4.75 volts. This allows the 
microprocessor to complete any pending database transactions and do an orderly 
shutdown of the DRAM. This is accomplished by monitoring the unregulated power 

with the Seiko S80731AN power supervisor IC (U2). After the unregulated supply 

• . ... . - 

drops below about 8 volts, the S80731AN will assert -PWRBAD. This causes an 
interrupt in the microprocessor which will initiate power down subroutines. U3 
monitors the 5 VDC supply and controls the -RESET line into the DBE 1200. This 
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generates a clean reset signal during power up and power down. LR. 
TRANSMITTER 116. 

The LR. Transmitter 116 function is done with a MC68HC05C9 
microprocessor. This microprocessor is programmed to interface with the software 
5 serial bus 1 10 for communication with the 8032.. This microprocessor can generate 
pulses on its output pin that simulate IR signals for most VCR'*." The ROM in the 
MC68HC05C9 contains the executable program and the codes and sequences to 
control a VCR via Infrared.. Port B on the MC68HC05C9 is used to set the serial 
address that it will respond to. The clock signal is generated by a programmable 
10 clock divider in the DBE1200 gate array. , • } ' . 

Figure 6 illustrates how packets 300, messages 302 and ? commands 304 are 
related. Figure ? provides further details of packets 3(Xh Unless otherwise noted,jall 
fields are binary 2's complement numbers. All undefined bits within fields are 
reserved, and initialized to zero. All multi-byte variables are stdred most significant 
15 byte first (big endian format), unless otherwise noted. Notable exceptions are the 
, . CI f ( r 16 311(1 CRC32 fields, which are stored in reverse order, least significant byte 
first (little endian format). 

. v ^ A11 viewable text strings are comprised exclusively of pjrintable characters, 
where printable is defined as any character with ASCII values jn the range of 32 
(20H) to 122 (07AH), inclusive. Both upper and lower case letters are supported. All 
fixed fields which contain ASCII strings that do not fill the fieWare to padded with 
NULL (ASCII value 0) characters. Unless otherwise specified, swings which do fill " 
the field are not NULL terminated. 
Packets 300 

25 f Packets 300 consist of error detection information and information to be 
operated on by a subscriber unit. The packet fields shown in Figure 7 have the 
following descriptions, as shown in Table VI: 



20 
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Field 
sync 



size 



10 



packet time stamp 



15 



20 



vbi Stream ID 



25 



CRC1 



30 



Message 



Description 

Code number indicating the start of a Packet. Used to locate 
the start of a Packet when transmission errors occur. Value is 
always 2C(hex). 

Is the total size of the packet, in bytes. This includes the 
'sync', 'size' 'packet time stamp, *CRC1\ 'Message', and ... 
'CRC32* fields. There is no official maximum size for 
packets. All units which listen to packet streams should be 
prepared to ignqre(any packet that exceeds the maximum 
packet size the unit can handle. First generation Subscriber 
Units ignore any jacket that is greater than 2048 Bytes in 
length, total. 

Is the four byte time stamp of the minute the packet Was 

transmitted. This field is used by subscriber units to 

* .< ■ ■* • 

_ differentiate data streams on recorded mediums (such as VCR 

tapes) from live dsga streams. The time is encoded as minutes 

since January 1, lg92, rounded to the nearest minute 

boundary. Since packet headers are not guaranteed to be 

Jransmitted on minute boundaries, the maximum_errpr of this 

field is up to +/-30 seconds. 

Is a two byte num^r identifying the unique ID of the VBI 
stream die romn^ndjias been admitted on. This field rnay 
be used by subscriber units to identify thetir assigned "Jiome" 
data stream, where their key distribution message will be 
broadcast. 

Least significant word (16 bits) of the 32 bit cyclic 
redundancy code (CRC-32) value for the Packet header . The 
CRC is computed over the 'sync* and 'size' fields. This field 
is stored least significant byte first (little endian format). 
Information bearing portion of a Packet. Contains one or 
more Commands. 
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Command An entity that contains information pertaining to a specific 

portion of the database, or time markers, or user authorization 
information. Each type of Command contains a unique code 
number and a length field. 
5 CRC32 32 bit cyclic redundancy check (CRC-32) value. The CRC is 

computed over the 'sync', 'size', 'CRCr, and 'Message' 
fields. The CRC32 generator polynomial is 

+ 1 . This field is stored least significant byte first (little 
10 endian format). . 

Table VI 

Messages 302 

Messages 302 are the information bearing portion of a Packet 300. As 
shown in Figure 8, they consist of one or more Commands 304. Messages contain 

15 an integral number of Commands and Commands are not split between Messages. 
The 'size* field in the packet header is used to determine when all Commands have 
been processed. The optimal size of the Message field is 250 byte^or less. 
Commands that are larger than 250 bytes should be contained singly in a packet. The 
bytes following the last byte in the last command is always the firsjj byte of the 

50 CRC32 field. 
Commands 304 

Commands 304 are the elements of the StarSight Data Transmission Network 



required to build a TV schedule database, maintain the current time of day, and 
handle user authorization and security issues. 1 

The different Commands are distinguished by a unique valine known as the 
'Cmd type'. It is contained in the least significant 6 bits of the Command's first 
byte. A total of 64 unique command types are possible. The second field is 'Cmd 
length', used to determine the byte size of the Command. The size includes the 
'Cmd type' and 'Cmd length' fields. The 'Cmd length' field may be a one or two 
byte quantity. Table II lists all commands and specifies the size of the 'Cmd length' 
fields. Also included in this table is the encryption offset for the command. This 
concept is discussed in the section that follows this table. 
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Table VII 

Subscriber units that do not recognize a command type (as will happen in the 
future when new commands are implemented) must compute the Command length 
5 and skip over/ignore the command. 

The most significant bit of the Command's first byte is a flag that signals 
whether the command is encrypted or not. When set, the command is encrypted, 
when clear, not encrypted. It is probable that the only commands which are passed 
to the Subscriber Unit in an encrypted format are Show list. Authorization, and Key 
10 Distribution Commands. The Subscriber Unit should however be prepared to decrypt 
any command. 

The starting offset of the encrypted portion of the command is also listed in 
die previous table. Most commands leave a portion of their contents in the clear so 
that network entities which process the packet stream may' filter out unneeded 
15 commands without decrypting the guts of the command. (Note that die encryption 
offset for future commands may be changed when the commands are actually 
implemented.) 

The second most significant bit of the command's first byte indicates which 
of two program keys are to be used when decrypting the coinmand. When the bit is 
20 clear, decryption program key 0 is used, when set, key 1 is to be used. 

Since it is necessary to add an initialization vectored pad characters, the 

•*»- - -vw '<aj£. ^ r - -a .- p?.- •** .< .... : \£ vw^v*^*- &y ~\c - \ 2*9- «~ ' J >■■•■ '£ '•' 1 - >•••*•".,£ . -z. - 

process of encrypting a command increases the amount of memory necessary for 

storing the command. The initialization vector is an 8 byte field that is always 

prepended to the start of the encrypted byte stream. The padding is appended to the 

25 byte stream before it is encrypted/The purpose of the padding is to help the Security 
Module determine if the encrypted data has been "tampered" with. Enough pad 
characters are added to make the length of the raw data stream a multiple of eight. If 
the length begins as a multiple of eight, 8 pad characters are added. The value of the 
pad characters are the number of fill bytes that have been added; i.e., if 3 extra 

30 bytes are added to the command then each fill byte will have the value 3. The 
encrypted data within the Command is stored as shown in Figure 9. 
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Future revisions of this command set may append field definitions onto 
existing commands. Command processors should be prepared to ignore all data that 
follows the last recognized field. 

Some commands are addressed to particular units or groups of units. Units 
5 are addressed using a logical address that is comprised of two parts; the four byte 
batch number and the one byte unit number. The batch number is used as the group 
address, directing the command to a group of units that share the same batch 
number. A batch number of zero has a reserved meaning ; it addresses all units. All 
other possible batch numbers are valid addresses, (i.e. a command transmitted with 

0 batch number = 0 is intended as a system wide broadcast, while a command with 

>« ■ , 

batch address 23456 is directed towards units in batch group 23456 only. Units in 
other batch groups should ignore the latter command). 

• . ' • • - - 

The unit number is used to identify a particular unit within the batch group. 

Up to 255 units may be contained withih^a batch group. The unit number of zero has 

5 the reserved meaning of addressing all unit's within a batch group, (i.e. alogical 

address with batch number=23456, unit v number=0 is directed to all units within the 

batch group 23456). 

Commands required to build the subscriber unit database are typically sent 

repetitively, in the order shown in Table Vm: 

Theme Categories Always acquired (If not already acquired). 

Theme Subcategories Always acquired (if not already acquired). 

Regions Region's list of channels is acquired if the unit has-been 

authorized. 

Channel Data Channel data is acquired if the channel is in the region's list 

of channels. 

Show lists Show list is acquired if it is applicable to an active channel in 

the region's list of channels. Show lists give the schedule 

• - - • - • - 

data for a single channel for a single day. The current day's 

data is sent more often than succeeding day's data. 

Show Titles Show title is acquired if it is referenced in some acquired 

Show list and the subscriber unit does not already have it. 
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Show Descriptions Show description is acquired if it is referenced in some 

acquired Show list and the subscriber unit does not already 
have it. 

Key Distributions Key distribution commands are always processed, if the batch 
5 address of the command matches the unit's assigned batch 

address. 

Table Vm 

Other messages are interspersed in this cyclic stream on a random basis as 
required. Note that transmission errors can cause missing messages and commands 
can therefore be received out of order. Note especially that there can be gaps in the 
Show lists. Subscriber units must be able to handle missing and out of order 
messages. 

The following sections describe each command. Commands are shown in 
their non-encrypted form, but the reader must be aware that the above mentioned 
15 modifications due to encryption may be made to any command. ' 
Time Command '' ■ 

Time Commands (Figure 10) specify the current time of day and date. They are sent 
periodically, at a predetermined rate. Subscriber Units 52 (Figures 1-4) should reset 
their current time of day and date to agree with the value received in this message. 
The fields of time commands shown in Figure 10 are as described in Table DC- 
Field Description 

Cmfltype Command type = 1. Identifies command' as a Time 

Command. 

enc fig Flag indicating if the current command has been encrypted. 

25 Command type and command length fields are never 

encrypted. 0=not encrypted, l=encrypted. 
key ID Decryption key ID. Identifies which of two current 

"program" decryption keys should be used to decrypt this 

command. 

30 Cmd length Number of bytes in the command (including the type and 

length fields). 
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Time Current time of day and date encoded as number of minutes 

from midnight, January 1, 1992. Time of day and date is 
Greenwich Mean Time. 
DS fl 8 Daylight Saving flag. Flag indicating if Daylight Saving is in 

5 effect. Sent whether or not default time zone uses Daylight 

Saving time. 0 = Daylight Saving not in effect, 1 = 
Daylight Saving in- effect, 
sign flg Sign bit for the default time zone offset field, which follows. 

^ > If set, it indicates the time zone offset is negative, and should 

■i . ,. . »„; ... ...... 

be subtracted from [Greenwich mean time. (For data provider 
stations West of the Greenwich Meridian, i.e. the entire U.S. 
and Canada). Nofc^that this implies the time zone offset field 
is not a two's complement binary number, 
default time offset Four bit field indicating the number of hours offset from 
15 Greenwich Mean 3Time to the time zone of the data provider 

]l . station ^ansinittin^the StarSight data. Intended to be used 

when displaying local time before the Subscriber Unit has 

been authorized (w£ich sets the real time zone). The legal 

• : ' ' . -r " ■ - j.\ 

range for this fieW is from 0 to 12 binary. 
*' ' '■■ y- '** '-y - : **. ' rw* y . '■ ' 1 ' * -*. "' 

2 9 _ time (sees) Is the low order srconds part of the time field, stored 

. '* previously in the command. The resolution of this field is 
, , . seconds past the minute. T^ie legal range is 0 to 59 inclusive. 

^ _ . v ._ # Table DC 

Daylight Saving Time Change Command s 
25 The Daylight Saving Time Change Command defines when the next Daylight 

Saving time changes will occur so that displays of schedule data for time periods that 
contain these changes can show the correct adjusted local time. Subscriber units 
™ us * ^ their Time 2006 °f fset (obtained from the Authorization Command) to 
calculate the GMT time for the change corresponding to their local change time. 

30 Show list entries after this calculated GMT time should be shown with a time offset 
affected by die upcoming Daylight Savings state. The fields in the Daylight Saving 
Time Change Command as shown in Figure ll are defined in Table X. 
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Crnd type 
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key ID 



0 Crnd length 
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Saving 

5 " 
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Saving 
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Description 

Command type = 2. Identifies command as a Daylight 
Saving Time Change Command. 

Flag indicating if the current command has been encrypted. 
Command type and command length fields are never 
encrypted. O=not encrypted, 1= encrypted. 
Decryption key ID. Identifies which of two current 
"program" decryption keys should be used to decrypt this 
command. 

Number of bytes in the command (including the type and 
length fields). 

Time of day and date wheri the Daylight Saving time would 
be enabled at the Greenwich Meridian. Encoded as number 
of minutes from midnight,' January 1, 19JJ2. Time of day and 
date is Greenwich Mean Time. The: enable time is always less 
than the disable time. 

Time of day and date when the Daylight Saving time would 
be disabled at die Greenwich Meridian.^ Encoded as number 
of minutes from midnight, January 1, 1992. Time of day and 
date is Greenwich Mean Time. The disable time is always 
greater than the enable time. 



Table X 



4~ " 

■9... 



The Region Command identifies all channels for which StarSight Data is 
available and could possibly be received by a Subscriber Unit in the given region. 
One Region Command is sent for each region in the area serviced by a data provider 
station. For example, the channel lineup for each cable system constitutes a region. 
The Authorization Command sends the region ID. Once the region ID is known, the 
Channel Data for each channel in the region can be acquired from the Channel Data 
Commands. 

The channel IDs in this command are not needed by the subscriber unit after 
it has acquired the Channel Data for each channel in the user's region. However, 
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the region ID and version must be held in case the Channel Data is lost (e.g., power 
outage) or has changed and must be re-acquired. 

Channel ID entries are listed in the default order that Subscriber Units should 
display them in until the user has changed the sequencing using a setup screen. 
Channel ordering is more or less numerical, and Channels such as HBO and 
DISNEY are all given a native channel number equal to 1 and probably ordered 
alphabetically by the 'name-affiliation' field. 

Only Base channels are sent in a Region Command (see Duplicate Channels 
Command). The fields in the Region Command as shown in Figure 12 are defined 
in Table XI 

r .( ■ 

Description 

■ ; • > - % - • - ■ •■■ ■ ■ 

Command type = 3. Identifies command as a Region 
Command. ^ ' ' ' ' ' ' "' ^ 
Flag indicating if/the current command has been encrypted. 
Command type aj^d command length fields are never 
encrypted. 0=nq£encrypted, 1 =engrypted. 
Decryption key ID. Identifies which of two current 
"program" decryption keys should be used to decryptthis 
command. 

Number of bytes Jn the command (including the type and 
length fields). 

Unique region ID^number that must match one of the region 
IDs received injhe Authorization Command. Identifies the 
region for which the fpllowing list of channel IDs is 
appropriate. This ;field is never to have a zero value. 
Indicates if region is a broadcast, cable, or satellite system. 
(O=broadcast, 1 = standard cable, 2=IRC cable, 3=HRC 
cable, and 5=satellite. All other values are undefined.). 
Offset, in units of 1/2 hours from 6:00PM, to prime time for 
the region. E.g.; prime offset = 1 means prime time starts at 
6:30 PM, = 2 means prime time starts at 7:00 PM, etc. 
Is a flag indicating how the date field in this command should 
be interpreted. If this flag is set, the date represents when the 
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information in this command expires. If the flag is clear, the 
date represents the time the information in this command 
becomes valid. 

Specifies the time when the information in this command 
either expires or becomes active* See the explanation of the 
date type flag. The date is encoded as number of minutes 
from midnight January 1 , 1992, Greenwich mean time. 
Number of channel IDs in the region. This number must be 
greater than 0. 

Channel ID number used to identify the Channel Data 
Commands required to assemble channel data for all channels 
in the subscriber's system. This field is never passed with a 
zero value. 

Channel number used to tune a TV/VCR to this channel. 
Maximum tunable channel is channel 511. 
Note: tune channel number is sent in thi| command to avoid 
having to send a Channel ID entry for each cable system that 
places the channel on a different tuning channel number. 
E.g.; HBO might be on channel 10 on one cable system and 
"on channel 25 on another. Putting the tuning channel number 
here means only one HBO entry needs to be sent in the 
Channel Data Commands. T 
This field has no meaning if region typels broadcast. If 

... K-^ • - - • 

region type is satellite, this field indicates the band, (00=C 
Band, 01 =KU Band, and 02 & 03 are undefined). If region 
type is any of the cable types, this field indicates what source 
this channel is on (00 - no source specified, 01 = source A, 

02 = source B, 03 = source C). 

3 bit field which indicates the type of channel (00 = no 
special attributes, 01 =extended basic, 02 = premium, 03 = 
pay per view, 04= video on demand, all other values are 
reserved.). 
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5 bit field representing the alphabetic portion of the 
alphanumeric satellite identifier (i.e. the 'S' of satellite S4). 
This field is present (in all Channel ID entries) only if the 
'region type' field ;>= = Satellite Field value 1 represents the 
letter 'A', 2 is 'B\ etc.. The legal range for this field is 1-26 
inclusive, representing the alphabetic characters 'A' through 
'Z\ ' K ■ 

5 bit field representing the numeric portion of the 
alphanumeric satellite identifier (i.e. the '4* of satellite S4). 
This field is preterit (in all Channel ID entries) only if the 
'region type' fielcT= = Satellite. The field is broken up over 
two consecutive bjps. The legal range for this fipld is 1-31 
inclusive. 

6 bit field repr^enting the transponder number to be used to 
tune to this chann^ on a Satellite system. This field is 
present (in all Channel ID entries) only if the /region type' 
field = = Satellite. This field is never passed with 3>zerq 
value. It's legal range is 1-63 inclusive. 

.... _ lafekig ; _ . r 



The Channel Data Command givis channel information used for various 
displays. Channel Data Commands qre sgnt for each channel in all the regjpns 
serviced by a data provider station (PBS Ration node). The subscriber unit compiles 
information on all the channels in its region using the Channgl Data Commands that 
contain a Channel ID entry matching onejn its region list. 

Only Base channels are sent in Channel Data Commands (see Duplicate 
Channels Command). The fields of the Qhannel Data Command as shown in Figure 
13 are defined in Table XII. 



30 



Field 
Cmd type 



Description 

Command type = 4. Identifies command as a Channel Data 
Command. 
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Flag indicating if the current command has been encrypted. 
Command type and command length fields are never 
encrypted. 0=not encrypted, l=encrypted. 
Decryption key ID. Identifies which of two current 
"program" decryption keys should be used to decrypt this 
command. 

Number of bytes in the command (including the type and 
length fields). 

Number of Channel ID entries in the current command (not 
the total number in the system). This field^must always have 
the value of 1 (i.e. only ONE channel entry can be included 
in each command.) 

Most significant bit for the 'native channel nbr' field. 

Channel ID number used to identify the Channel ID entries 

that match those in the subscriber's region. 

Flag indicating if the channel's name should" be displayed as a 

number or as a three character text string. (0=number, 

1 =text). This flag must be set if the native channel number is 

specified as zero. 

The channel number associated with the channel if it were in a 
broadcast region. This is the number used |p identify the 
channel when the 'name fig' is 0. Normally this number 
matches the tune channel number; however, on cable systems 
channels get moved around. E.g. channel 5, could be on cable 
channel 29. In this situation, the tune channel number will be 
29 while the native channel number will be 5. If the native 
channel number is zero, the name_flg field in this command 
must be set. 

A bit field indicating which characters from the name 
affiliation string should be used as the stations "call letters". 
The MSBit (bit 7) of this field represents the first byte in the 
name affiliation string (byte 8), while the LSBit (bit 0) 
represents the last byte from the string (byte 15). (i.e., a value 
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of 11110000B for this field, with a name affiliation string of 
KTVU-FOX would indicate the stations call letters are 
KTVU). 

If the name fig field is set, a total of one to four bits must be 
5 set in this field. 

name^affiliation Up to 8 character £SCH text string used to identify the 

channel for display purposes. Padded with Null characters if . 
less than 8 characters long. This string may not be NULL 
terminated if it is eight characters long. 
10 Table XII 

Show list Command 

Showjist Commands provide schedule data for one day for a given channel. 
Show list commands do not contain schedule gaps (even for periods when the 
channel is off the air). Show list commands are sent for every channel in all regions 
15 of the system. Show list commands contain multiple Show Slot entries, with each 
entry corresponding to a single show in tjjie channel's schedule. 

Show list Commands represent at least 24 hours of schedule data. The first 
entry for a show list begins at midnight, Greenwich Mean Time. Programs which 
^ straddle the boundary between cons^utiye Show lists are represented only once, in 
20 the Show list in which their start time resides. The next Show list represents the 

portion of time in which a program from'a previous Show list overruns into jt with a 
dummy show enfry. These filler entries ^ recognized using the 'dum fig', which 
when set indicates the entry for the showat this time slot can be found at the tail end 
of the previous day 's show list. Only the^first entry in a show list can have the 'dum 
25 fig* set. Dummy show entries operate identically to valid show entries, except that 
their title and description text may be substituted with something that labels it as a 
filler entry. If a program's start time coincides exactly with the Show list boundary 
time, it will be represented only once, in the next Show list. 

Show list Commands, when they are encrypted, are encrypted starting with 

> •.ti" 

30 byte 11 in the above diagram (i.e.; starting with the 'nbr show slot entries' field). 

This allows the Show list Commands to be discarded if they are not applicable to the 
subscriber unit's region or have already been received. Ignoring unneeded Show 
lists may help a Subscriber Unit's data processing throughput, since decryption is 
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time consuming. The fields of the Show list Command as shown in Figure 14 are 
defined in Table XHL 



Field 
Cmd type 

enc fig 



key ID 



Cmd length 



version 



■ v. 



Channel ID 



start time 



Description 

Command type = 5. Identifies command as a Show list 
Command. 

Flag indicating if the current command has been encrypted. 
Command type and command length fields are never 
encrypted. 0=not encrypted, l=encrypted. 
Decryption key ID. Identifies which of two current 
"program" decryption keys should be used to decprpt this 
command. 

Number of bytes in the command (including the type and 
length fields). 

Show list version number. Used to identify when changes 

, ... .... . ' .i" ' . • . : . 1 jj.: . ... . ,- \ 

have been made to the Show list for the given daj. Version' 

starts at 0 when first sent over the network and increments for 

every change to the Show list for that day within the time 

period (i.e. one week) that the given day is active. If the 

version field differs from the value currently held by the 

subscriber unit then the new schedule replaces the current 

one. 

Channel ID number identifying the channel whosl schedule is 

■ "... . • .*= 

being sent. Matches the channel ID number in one of the 
Channel Data Command entries. This field will never have a 
zero value. f 
Start time and start date for the first show in this Show list 
command. Encoded as number of minutes from midnight 
January 1, 1992, Greenwich Mean Time. Start times for 
subsequent shows are calculated by adding successive 
duration's from each Show Slot entry. Thus, a show that 
starts in' one day and finishes in the next (e.g., Johnny 
Carson) would be the last show in the list. 
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nbr show slot entries Number of shows on this channel for the entire day, counting 

the dummy entry if one exists. 
DID fl S Flag indicating if a DID field is present in the current Show 

Slot entry; 0=not present, 1 =present. 
5 grP % Show group flag indicating if this show is a member of a 

show group. 0=no, 1 =yes. 
pay/view fig Indices show is a pay per view event. 1 = yes, 0 = not a 

pay/view. 

f giP flg Show group flag indicating if this show is a member of a 

10 show £roup. 0=no, 1 ==yes. 

dum flg Dummy entry flag. Indicates that the program at this time slot 

can be found at the end w the previous day's Show list. Only 
the first entry in a showflist may have the 'dum flg' set. 

duration Show duration in units of- 1 minute. The minimum total show 

' SL ..... .*>; r ' \y : v.;. ': . . , \* . . Ss ... • 

15 duration is 5 minutes, the maximum is 4 hours, or 240 

minutes. 

SID Show ID number. Unique 20 bit number used to identify the 

* . * '%*:-•" - * I " s * - ' •«* • 

Show Title command containing the show's title. This field 

may have a zero valu6. which indicates no show information 
20 is present. 

DID Description ID number/ Unique 16 bit number used to 



I identify the Show Description Command, which contains the 

^ _ show's episode description. If a description for this show 

does not exist, die DID flg will be left clear and this field will 
25 be omitted. This field may not have a zero value. 

show group ID Show group ID number. Identifies program as being a 

member of the set of programs that all have this same group 
ID number. Field is only present if the 'grp flg' field =1. 
This field may not have a zero value. 
30 Note : A SERIES recording for a program that has a show 

group ID number will cause all members of the group found 
on the same channel to bfe recorded. Record queue entries for 
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show groups are deleted 2 weeks after the last recording is 
made so that users do not have to turn off group recordings. 
Table XIII 

Show Title Command 

5 Show Title Commands contain the name of a program (e.g. COSBY SHOW) 

and some program attributes used in Theme searches. Show titles are usually 
compressed using a Huffman encoding scheme. 

The uncompressed show title must be between 1 and 86 bytes in length, 
inclusive. Since the display capabilities of Subscriber Units is limited, titles which 
10 are greater then 38 bytes in length may be truncated. 

Show Title Commands must be saved in the database if the show is in the 
Show list for at least one channel in the subscriber's region. All^ther Show Title 
Commands should be ignored. Show Titles that are needed are recognized by 
matching the SID number in the Show list with the SID number in the Show Title 
15 Command, the fields of the Show Title Command as shown in figure 15 are 
defined in Table XIV. 
Field Description 

Cmd type Command type = 6. Identifies command as a Show title 

Command. ' ^ 

20 enc fig Flag indicating if the current command h^ been encrypted. 

Command type and command length fields 6 are never 
encrypted. 0=not'encrypted, 1 =encryptedf 
ke Y P Decryption key ID. Identifies which of two current 

"program" decryption keys should be used to decrypt this 
25 command. 

Cmd length Number of bytes in the command (including the type and 

length fields). 

cmp fig Flag indicating title is compressed. A few titles are longer 

when compressed using the Huffman encoding scheme (e.g. 
lots of 'x's or 'q's). 1 =title has been compressed, 0=title is 
uncompressed ASCII. 
cc Flag indicating show contains closed captioning information 

(VBI line 21). 0=not close captioned, l=closed captioned. 
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Flag indicating show is broadcast in stereo. 0=not stereo, 
1 =stereo. 

Flag indicating if show is broadcast in black & white or color. 
0=color, 1 =black & white. 

20 bit unique number identifying this show. This Show Title 
Command is of interest to the subscriber unit only if this 
number is also found in the Show list for some channel in the , 
unit's region. This, field is never passed with a zero value. 
Number that identifies the Theme type and genre information 
appropriate for this program. Used fop Theme searches- 
Subcategories hav^ sets of Theme ID numbers identifying the 
types of shows to \pe selected when a Theme search is % 
performed for that sub category. Shows whose 'Theme ID* 

. field matches one of the values in the set are selected. A zero 

* - • - • • ' l * - • ■-■ ... v .* 

value indicates np jheme information is present. 
Huffman encoded pr straight ASCII text string giving the 
show's title. Huffman encoding scheme is described in 

Appendix A. The string is always NULL terminated, Hie 

*. ■ ■> * 

. . , ^ NIHJ. charac|^ 

... 3^av . : ;f' 

Show Description Command SL„ 

Show Description Commands contain the description of an episode of a 
program and some program attributes uspd in Theme searches. Show descriptions 
are usually comprised using the same ^ffinan encoding scbeme used for show 
titles. • 

The uncompressed show description must be between 1 and 162 bytes in 
length, inclusive. Since the display capabjlities of Subscriber Units is limited, 
descriptions which are greater then 120 bytes in length may be truncated. 
Show Description Commands are sent for all shows that have descriptions in all 
regions serviced by the data provider. Show Description Commands must be saved 
in the database if the DID is referenced in the Show list for at least one channel in 
the subscriber's region. All other Show Description Commands should be ignored. 
Show Descriptions that are needed are recognized by matching the DID number in 



WO 95/31069 PCT/US95/05169 

68 

the Show list with the DID number in the Show Description Command. The fields 
of the Show Description Command as shown in Figure 16 are defined in Table XV. 
Field Description 

Cmd type Command type = 8. Identifies command as a Show 

5 Description Command. 

enc fig Flag indicating if the current command has been encrypted. 

Command type and command length fields are never 
encrypted. 0=not encrypted, 1 =encrypted. 
key ID Decryption key ID. Identifies which of two current 

10 "program" decryption keys should be used to decrypt this 

command. 

.... v: . . ■ 

Cmd length Number of bytes in the command (including the type and 

length fields). * ' 

DID Description ID number. Unique 16 bit number identifying 

15 this episode description. This Show Description Command is 

of interest to the subscriber unit only if this number is also 
found in the Show list for some active channel in the unit's 
region. This field is always non-zero. 
_ cmp fig Flag indicating description is compressed, Mfew descriptions 

20 are longer when compressed using the Huffman encoding 

scheme (e.g. lots of 'x's or *q*s). 1 =title his been 
compressed, 0=title is uncompressed ASCII,; 
CC Flag indicating show contains closed captioning information 

(VBI line 21). 0=not close captioned, 1 =clbsed captioned. 
25 stereo Flag indicating show is broadcast in stereo. 0=not stereo, 

1= stereo. 

BW/C Flag indicating if show is broadcast in black & white or color. 

0=color, l=black & white, 
rating fig Flag indicating if the command has the ratings fields in bytes 

30 7, 8, and 9. Otherwise these bytes are absent and the Theme 

ID field begins in byte 5. 0=ratings bytes not present, 

1 = ratings bytes present. 
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Three bit field representing the critic's rating of the movie. It 
is a number which is interpreted as follows : 0=no rating, 

l=poor 4=exc^llent. Values 5-7 are reserved. 

Four bit field indicating the movie audience suitability rating. 
0=no rating, 1=G, 2=NR, 3=PG, 4=PG13, 5=R, 6=X, 
7=NC17. Values 8-15 are reserved. 

Eight bit mask indicating program's attributes such as violence 
or nudity. 
Bit 
0 
1 

2 v 
3 
4 
5 
6 

7 adult language 

The year which the episode was produced minus 1900 10 . For 
example, a movie pi^uced in 1943 would have the biiwy ; 
value 4310. This b#e is present only if the 'rating fig' is 
set. The value 00 in&cates that the production year has not 
been specified. 

Huffman encoded or strsught ASCII text string giving the 
show's episode description. Huffman encoding scheme is 
described in Appendix A. The string is always NULL 
terminated. The NULL character is appended before it is 
Huffman encoded. 

Table XV 

Theme Category Command 

The Theme Category Command specifies the major categories displayed in 
the subscriber unit's theme function. These categories form the first level of indexing 
in the hierarchical theme search function. Fof each major theme category a unique 8 
bit ID number and a text string is specified, the text string names the category 
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entry. The entries are listed serially within the command in the suggested 
presentation order. 

The command includes a version number which is incremented each time the 
theme category command is changed. Subscriber Units should replace existing 
versions of the command stored in memory when a command with a differing 
version number has been transmitted. The fields of the Theme Category Command 
as shown in Figure 17 are defined in Table XVI. 
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Description 

Command type = 1 1 (0BH). Identifies command as a Theme 
Category Command . • 
Flag indicating if the current command has been encrypted. 
Command type and command length fields are never 
encrypted. 0=not encrypted, l=encrypted. % 
Decryption key ID. Identifies which of two current 
"program" decryption keys should be used to decrypt this 
command. 

Number of bytes in the command (including the type and 
length fields). 

Theme Category set version number. Version number 

changes if any category is added, deleted, or the text changes. 

A completely new set of categories should be Acquired when 

the version number changes. ^ 

Total number of primary Theme categories; i.e;/ number of 

Theme category entries that follow. 

Unique 8 bit number used to identify corresponding sub 

category entries. This field is never passed with a zero value. 

An 8 bit flag word used to specify the properties of the theme 

sub-category. The meaning of each field in the flag word is as 

follows : 

Bit 0 : DISPLAY NAME WITH DESCRIPTION - when set, 
the theme category name may be displayed with the 
description of a show with this theme id. (Some category 
names like ALL or OTHER may appear awkward when 
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displayed with a description. These types of entries will have 
this bit cleared. Other entries, such as MOVIE or 
DOCUMENTARY are desirable additions to descriptions, and 
hence may have this bit set.) 
5 Bits 1-7 : RESERVED. 

Category name length Number of bytes in tjfje 'Category name' field. Used to locate 
^ start of the next «ptry and determine the length of the text, 
string that follows. This field will never have a zero value 
^ ... t ( fu ?t generation Subscriber Units will crash if this is passed as 

Category name Text string naming the category. This should be used to 
display the name of the category. The text isjin uncompressed, null terminated 
ASCII string. . ; 

, Table ivi 

15 Theme Sub-category Command 

The Theme Sub-category Command^ecifies the sub-categories displayed in . 
the subscriber unit's theme ftinction. These are displayed after the user has selected a. 
major theme category. Each major theme p^gory has one or more sub categories, 
which form the second level of the fiierarcfiicaT search scheme. The description of * 
20 each sub category includes the 8 bit ID of tte parent category, a unique 16 bit theme 
ID number and a text string which names th|entry. The entries are listed serially "\ 
within the command in the suggested presentation order. ¥ 

The command includes a version number which is incremented each time the 

... * ^— ■ • . 

theme sub-category command is changed. Subscriber Units should replace existing 
25 versions of the command stored in memory ^hen a command with a differing 

version number has been transmitted. All subscriber units should store these sub 
category names if they do not already have, an entry with the same Theme Category 
ID, Sub category ED, and version number. The fields of the Theme Sub-category 
Command as shown in Figure 18 are defined in Table XVII. 
30 Field Description 

Cmd type Command type = 12 (OCH). Identifies command as a Theme 

Sub-category Command. 
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Flag indicating if the current command has been encrypted. 
Command type and command length fields are never 
encrypted. 0=not encrypted, l=encrypted. 
Decryption key ID. Identifies which of two current 
"program" decryption keys should be used to decrypt this 
command. 

Number of bytes in the command (including the type and 
length fields). 

Unique 8 bit number used to identify the primary category 
corresponding to this sub category entry . This field will never 
have a zero value. 

7 bit unsigned number indicating the total number of Theme 
Subcategories; i.e., number of Theme sub category entries 
that follow. This field will never have a zero value (First 
generation Subscriber Units will crash if thisjs passed as 
zero). * 
Total number of bytes in current sub category entry including 
this byte. Used for determining the start offset for the next 
entry and the number of bytes in the 'sub cafegory name' 
field. This field will never have a zero valued 
An 8 bit flag word used to specify the properties of the theme 
sub-category. The meaning of each field in tfie flag word is as 
follows : 

Bit 0 : DISPLAY NAME WITH DESCRIPTION - when set, 
the theme sub-category name may be displayed with the 
description of a show with this theme id. (Some sub-category 
names like ALL or OTHER may appear awkward when 
displayed with a description. These types of entries will have 
this bit cleared. Other entries, such as COMEDY or DRAMA 
are desirable additions to descriptions, and hence may have 
this bit set.) 
Bits 1-7 : RESERVED. 
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Number of Themes ID entries that follow this field. In the 
above diagram, the value of this field 
would be *k\ This field will never 
have a zero value {First generation 
Subscriber Units will crash if this is 
passed as zero). J 

Set of 16 bit Theme ID numbers used to identify shows that 
should be selected when a Theme search is done for this sub 
category. That is^ any program whose Show Title or Show 
Description entry contains any one of these Theme ID 
numbers would be included in the list of shows selected by 
this Sub category /These theme ID's are sorted in ascending 
order. These fields will never have zero values, 
text string naming/the category. This should be used to ' 
display the name of the category. The text is an 
uncompressed, riuU terminated ASCII string. 
Table XVH 

Subscriber Unit Reset Command ' " r ■ 

'** The Subscriber Unit Reset Command allows tfie StarSight Control Center to 
reset selected subscriber units. Different types of reset can be sent The fields of 
the Subscriber Unit Reset Command as sjiown in Figure 19 are defined in Table 

xvm. ~ * " ' ■ 

Description 

Command type =13 (ODH). Identifies command as a 
Subscriber Unit R£set Command. 

Flag indicating if the current command has been encrypted. 
Command type and command length fields are never 
encrypted. 0=not encrypted, l=encrypted. 
Decryption key ID. Identifies which of two current 
"program" decryption keys should be used to decrypt this 
command. 

Number of bytes in the command (including the type and 
length fields). 



Field 
Cmd type 

enc fig 



key ID 



Cmd length 
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reset type Reset Control Bit Field : 

Bit 0 : When set instructs the unit to clear the semi-volatile 
memory where the acquired network data is stored. When the 
unit restarts, it will begin re-acquiring network data (also 
5 known as a cold boot). 

Bits 1-7 : Reserved. f 
serial nbr 5 byte serial number which idnetifies the subscriber unit this . 

command is addressed to. A serial number which is all zeroes 
indicates a "group broadcast", so all, subscriber units should 
10 be prepared to respond to such a command. 

Table XVIII 

Authorization Command 

The Authorization Command authorizes the subscriber unit to begin 

collecting and displaying schedule data. It is sent when a subscriber signs up for 

15 the StarS ight service. 

Until the Authorization Command is received, a subscriber unit does not 

^ • ■ - - ■ v* . 

know what region it is in, and hence, does not know which channels to collect data 

for. Similarly, it does not have the decryption key necessary to decrypt various 

commands until the Authorization Command is received. * 

■ •' • ? \ - ■ • ? . • ■ v.^fc-"- - • ' ' 

20 Authorization Commands are addressed to individual subscriber units using 

the serial number given to a Customer Service rep during the authorization process. 

The first generation subscriber units are limited to supporting a single region and one 

or two separate VBI lines on the same tuning frequency. The fields of the 

Authorization Command as shown in Figures 20-22 are defined in Table XIX. 

25 Field Description :r " 

Cmd type Command type = 14 (OEH). Identifies command as an 

Authorization Command, 
enc fig Flag indicating if the current command has been encrypted. 

Command type and command length fields are never 
30 encrypted. 0=not encrypted, 1 =encrypted. 

key ID Decryption key ID. Identifies which of two current 

"program" decryption keys should be used to decrypt this 

command. 
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Number of bytes in the command (including the type and 
length fields). 

Subscriber unit serial number assigned by the manufacturer. 
Used to address the subscriber unit during authorization or 
re-authorization. Subsequent commands are addressed to a 
subscriber unit usipg the batch and unit numbers. This 
number is given to the customer service representative during, 
the authorization process and determines the RSA public key 
used to encode the; encrypted portion of this command. 
72 byte block of authorization data, encrypted with the unit's 
factory assigned public key. The cryptogram must be decoded 
using the subscriber unit's private RSA key assigned to the 
StarStght Security processor at time "of manufacture. The data 
is stored as follows before encryption V 
32 bit number identifying the encryption group to which the 
subscriber unit tiel0ngs to. When combined with the one byte 
unit number that follows this element, a unique address for 
the subscriber unites formed. These numbers are assigned bv 

this command and txsed to address this unit or its' batcS ctoud 

. a • . . *? .. r 

in all subsequent commands. 

*"*"•*•*'• ' ■"' A " 

1 byte unit ID. ^ch unit within a batch group is assigned a 

unique unit ID. ^ ^ 

2 byte bit mask Indicating which StarSight services the user 
has subscribed to. ^The meaning of the individual bits is TBD. 
All bits are to be remain zero until defined. 

The first 8 byte decryption key. Subsequent Key Distribution 
Commands are addressed to this unit's 
batch assigned group to assign new 
program keys. 

The other 8 byte decryption key. 

Is the number of data bytes remaining in the authorization 

block, not including the empty reserved data block and this 
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field. In the current definition of this command, this field is 
equal to the constant 20 (14H). 
batch key 8 byte key assigned to this unit's batch group. This key is 

used to decrypt the program keys transmitted in the Key 
Distribution Command. 

Batch keys are only changed if the key is broken for a given 
batch. New batch keys are assigned to a batch by sending new 
Authorization Commands to each member of the group. 
DP source This field has the same meaning as the source field in the 

region command. It is intended to indicate which input source 
the data provider signal is on. 

" ' f ■ 

sign fig Sign bit for the time zone offset field, which follows. If set, it 

indicates the time zone offset is negative/ arijd should be 
subtracted from Greenwich mean time. (For Idata provider 
stations West of the Greenwich Meridian, Lei the entire US 
and Canada). Note that this implies die time zfine offset field 
is not a two's complement binary number. 
Four bit field indicating the number of houi£ offset from 
Greenwich Mean Time to the time zone ffie "subscriber unit is 
located within. Intended to be used when dfsjjlaying local 
time before the Subscriber Unit has been authorized (which 
sets the real time zone). The legal range for this field is from 
0 to 12 decimal. (This field should be interpreted identically 
to the default time zone offset field contained in the Time 
25 command.) 

VCR code group Code number identifying the group of VCR control codes to 
be used when commanding the user's VCR to do a recording, 
to rewind, etc. This field is defaulted with value 8000H, 
which means that no code group has been specified. 
30 Cable box code group Code number identifying cable box control codes to be used 

when commanding the user's cable box to change channels. 
This field is defaulted with value 8000H, which means that no 
code group has been specified. 
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Satellite code group Code number identifying satellite control codes to be used 
when commanding the user's satellite interface to change 
channels. This field is defaulted with value 8000H, which 
means that no code group has been specified. 

TV code group Code number identifying codes used to control the television 
remotely. This field is defaulted with a zero value. The 
specific meanings of th§ code groups are TBD. 

Primary Region ID Unique number identifying the region in which the subscriber 
unit is located. This field specifies the set of channels for 
which data is collect^ Jt corresponds with the region ID in 

the Region Command. First generation subscriber units can 

■ ? " ' ." 
. , , , collect data for onlyojig region. , 

°SA flg Daylight Saving applicable flag. Flag indicating if Daylight 

; Saving time is used .in fte subscriber's time zone. 0=no, 

Tune Chaiinei KlSB Most significant bit ofjfie tune channel 
number field, which follows. 

Channel ID number forthe station to be used for receiving all 
subsequent StarSight pp^imands. Normally this will be the, 
station used during the. authorization process, but load _ . ' 
balancing requirements may force a change. 

lis the tuning channel number of the data provider. This 

■ "\ ■ "' . " • V*-- • . - h- 

information is transmittgd in the authorization command, so 

that the subscriber unit does not have to wait for a Channel 

Data Command to interpret the Data Provider Channel ID 

field. The legal range for this field is 0 to 511, inclusive. 

5 bit field representing the alphabetic portion of the 

alphanumeric satellite identifier (i.e. the 'S' of satellite S4). 

Field value 1 represents the letter 'A', 2 is 'B\ etc.. This 

fields is specified as zero if the dataprovider is a non-satellite 

source. If this field is non-zero, it's legal range is 1-26 

inclusive, representing tjie alphabetic characters 'A' through 
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satellite numeric ID 



5 bit field representing the numeric portion of the 
alphanumeric satellite identifier (i.e. the '4' of satellite S4). 
The field is broken up over two consecutive bytes. The legal 
range for this field is 1-31 inclusive, 
transponder no 6 bit field representing the transponder number to be used to 

tune to this channel on a Satellite system. This fields legal 
range is 0-63 inclusive. 
VBI line nbr VBI line number to be used for acquiring StarSight data. 

VBI Stream ID Stream ID of primary data provider. The stream ID is 

transmitted with each time command. Subscriber Units may 

use this to identify the VBI stream they are listening to. This 

• - "t 

may be useful for Subscriber Units while searching for the 
home data stream after a cable company' lias made an 
unannounced change to its channel mappihg. 

RESERVED 10 byte field, reserved for future definitions. All first 

generation subscriber units will riot interpret the contents of 
this data block. 

Table XDC ^ 

Long Assign IR Codes Command ; 

The Long Assign InfraRed Codes Command specifies tfi^ControI codes to be 

■-*■->.>: ■•=■ /v.. . - i •• • -f .. -re- 

used by the Subscriber Unit Universal Remote Control chip to control a specific 

peripheral device. The codes which describe the IR blaster language may optionally 

be sent for those devices that are not in the URC chip's interrialllatabase. 

Transmission normally occurs while a Customer Service Rep is in contact with a 

user who has called StarSight because they did not find the code group for their 

VCR/Cable Box/TV in the Subscriber Unit manual. 

IR Codes may be sent either addressed to a specific unit via its Serial 

Number, or to groups of units with a given Product Code, Device Type (e.g. VCR), 

and Device ID. These commands may either be sent once per user request or 

repetitively when addressed to groups of SUs. The fields of the Long Assign IR 

Codes Command as shown in Figure 23 are defined in Table XX. 

Field Description 
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Command type = 22 (16H). Identifies command as a Long 
Assign IR Codes Command. 

Flag indicating if the current command has been encrypted. 
Command type and command length fields are never 
encrypted. 0 = not encrypted, 1 = encrypted. 
Decryption key IP. Identifies which of two current 
"program" decryption keys should be used to decrypt this 
command. 

Number of bytes in the command (including the type and 
length fields). J 

Subscriber unit serial number to which the command is 
addressed. A Serial Number of 0 means tfie command is 
addressed to all Subscriber Units having a Product tode, 
Device Type, and Device ID corresponding to the one in this 
command. 1 



A number corresponding to the way the components 
controlled by the^SU (i.e. TV, VCR, cable box) are connected. 
Values and configurations are TBD. 
Byte value whose; use depends on the product to wjhtich this 
command is addressed. For example, when addressed to a 

Zenith TV this vklue is the tuning method to be used with the 

. v : r- 
downloaded IR cgdes. 

' * - tf . 

Number identifying the type/model of Subscriber Unit to 
: • ' . ;yfr " ' • ■■ • ■■""7. 

which this command is addressed. Correlates with the type of 

URC chip in the SU. This command is ignored by a 

Subscriber Unit if this number does not match its Product 

Code when the Serial Number field = 0. 

Identifies the type? of device (VCR, Cable Box, TV, IRD, ...) 

that can recognize these IR codes. 

0 Cable Box 

1 TV 

2 VCR 

0C IRD ~ 
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Device ID Code group number for the device that recognizes these IR 

codes. The Subscriber Unit (only if it has a matching 

address) replaces whatever code group number it currently has 

for the given Device Type with this number. Thus the 

headend can directly set the code group for a specific user. 

This is not done if the Serial Number field in this command is 

0. In this case, the command is only processed if the user has 

already entered a code number that matches the Device ID for 

the same Device Type. 

Version Version number for the IR codes in this command. The SU 

saves the version number for each device type and only 
i ■ & 

processes those Assign IR Codes commands addressed to 

groups of units if its version number for die specified device 

differs from the version number in the command. 

Number of bytes in the IR Codes field. * ■ 

Information (normally IR codes) to be used %y the URC chip 

to control devices of the specified type. Structure within this 

field is determined by the URC chip manufacturer. 

" r "'" "" ; v table xx " v '^' r ' 

20 Key Distribution Command 

Key Distribution Commands give the current and next program keys to be 
used for decrypting encrypted commands.: Subscriber units must\|atch the data 
stream for a Key Distribution Command containing its batch numrer~ When the 
command is found it should send the authorization bit mask, both keys, and the 

25 authentication data field to the StarSight Security processor. If the bit in the 

authorization bit mask corresponding to the subscriber unit's unit number is 0 then 
the subscriber unit has been de-authorized and must suspend data collection. The 
fields of the Key Distribution Command as shown in Figure 24 are defined in Table 
XXI. 

30 Field Description 

Cmd type Command type = 17 (01 1H). Identifies command as a Key 

Distribution Command. 
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enc fig Flag indicating if the current command has been encrypted. 

Command type and command length fields are never 
encrypted. O=not (encrypted, 1 = encrypted, 
key ID Decryption key ID. Identifies which of two current 

5 "program" decryption keys should be used to decrypt this 

command. .; 

Cmd length Number of bytes in the command (including the type and 

length fields). 

batch nbr 32 bit number identifying the encryption group to which the 

10 ^ ^ _ subscriber unit belongs. This number was assigned during the 

authorization process. 

authorization bit mask 256 bit mask (32 bytes) with each bit corresponding to one 

unit in the batch. *The bit applicable to a subscriber unit is the 
bit corresponding 'to the unit's unit number. Bit is set (=1) if 
15 the unit is authored and reset (=0) if not. ; ■ 

program key 0 _ Cryptogr^ encoded using the b^ch key assigned to the 
subscriber unit's |roup. The StarSight Security processor 
uses this key to (jecrypt encrypted commands when the 'key 
ID' field = 0, 

20 program key 1 Cryptogram encoded usjpg the batch key assigned to die 

^ ^ subscriber unit's gqup. The StarSight Security processor 

uses this key to decrypt encrypted commands when th£ 'key 
""'[ ID' field = 1. > J 4 
authentication data 4 byte value used by die StarSight Security processor to 
25 authenticate the authorization bit mask and program key fields 

in this command 

Table XXI 

Subscriber Unit Command 

^ This command is used to transmit data bytes to one or more subscriber units. 
30 The definition of the format and contents is private to subscriber units. The network 
does not attempt to interpret the data. 

This command provides a hook for transmitting commands and initialization 
data to subscriber units during development, without having to define separate, 
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formal, network messages for each function, many of which may be temporary in 
nature. The fields of the Subscriber Unit Command as shown in Figure 25 are 
defined in Table XXII. 



Field 
Cmd type 

enc fig 



key ID 

Cmd length 
cmnd sub-type 



SU Serial Nbr 



Description 

Command type = 24 (018H). Identifies the command as 
Subscriber Unit Command. 

Flag indicating if the current command has been encrypted. 
Command type and command length fields are never 
encrypted. 0=not encrypted, l=encrypted. 
Decryption key ID. Identifies whjch of two current 
"program" decryption keys should be used to decrypt this 
command. 

... . " c&. 

Number of bytes in the command (including the type and 

length fields). 

1 byte field indicating what type of subscriber unit 

command this is. The following command types have 
been defined: 

01 : Enter Diagnostics Menu if this command is 

addressed to the unit ' * 

All other type values are reserved. 

Is the assigned 5 byte serial number of the Subscriber Unit. 

All zeroes in this field indicates a group broadcasuo all 

subscriber units. ^ 



Table XXII 



The following describes the Subscriber Unit 52 Database Engine Internal 
Data Structures. The general nature of the Subscriber Unit data is hierarchical. The 
schedule data hierarchy of data structures in descending order follows: 
CHANNEL DATA TABLE Contains Subscriber Units list of channels 
SHOW LIST Contains a list of Show Titles, descriptions, start 

times, and durations for a channel. 
SHOW TITLE Contains the Show Title attributes and title text. 
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SHOW DESCRIPTION Contains show ratings, attributes, and description 

text. 

Theme Categories and Theme Subcategories are used to select shows for 
viewing. They share a common data value (Theme Indexes) that are used to extract 
5 shows that match a Theme Category /Subcategory pair. The Theme data hierarchy 
in descending o^der follows: •£ 
THEME TABLE Table of Theme Categories 

THEME SUB TABLE Table of Theme Subcategories 

THEME SHOW; TABLE Table of Theme selected shows 

10 For a description of Network Commands received by the Subscriber Unit see the 

.... ........ . • f y ■ - - ■ * t 

InSight Data Transmission Network Protocol description. 
Database Memory Pool Overview 

- / ■ - • £ ■ • • • 

The Memory Manager allocates aiid frees Blocks of Memory as requested by 
the application portion of the Subscribed /Unit. The application software references 

15 Memory Blocks via a HANDLE. The handle of a memory block is an index to a 
table entry containing a POOL INDEX, the POOL INDEX is a scaled address that 
translates into the address of a MEMORY BLOCK. The HANDLE approach allows 
MEMORY BLOCKS to be relocated jE^stem objects age and die, without requiring 
specific updatingof application data structures^ 

20 The Memory Manager periodicalV runs a garbage collection process to 

collect unused MEMORY BLOCKS and recombine them into larger blocks. Because 

: ~f ~ - • tr 

applications reference MEMORY BLOCKS with HANDLEs through the HANDLE " 

■ : v »-r^'.< ■ - . " t > * t ^" ; /;k0^^.' 

TABLE, MEMORY BLOCKS can be rekicated with specific updating of application 

data" structures. In addition the memory pool can be temporarily locked to prevent 

25 the relocation of blocks during critical periods. 

Each MEMORY BLOCK contains as the very first element the size of, and 
the OBJECT TYPE of the Memory Block. This aids in the relocation and merging 
of MEMORY BLOCKS. J 

The OBJECT TYPES break up into two main groups. The small OBJECTS 

30 which always can be defined in less than 16 Blocks of Memory. Currently each 

block of memory is 16 BYTEs long,. Small OBJECTS have their OBJECT TYPE 
encoded in the first NIBBLE, and the length in blocks encoded in the second 
NIBBLE of the first BYTE of the MEMORY BLOCK. Large OBJECTS have their 
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OBJECT TYPE encoded as the first BYTE of the MEMORY BLOCK , and number 
of allocation units as the second BYTE of the MEMORY BLOCK. 

If the first BYTE of the MEMORY BLOCK bit wise ANDed with OxCO 
is 0, then this is a Large OBJECT, otherwise it is a small OBJECT, 
Database Memory Pool Access Scheme 

A schematic representation of the database memory pool access scheme is 

shown in Figure 26. Further details are as follows: 
Handle Table 

The Handle Table is a fixed allocation table, as shown in Figure 27, 
containing two types of entries; free entries and in-use entries. Free entries will 
always have their 2 MSBs set so as to not be confused with in-use entries. 

In-use entries contain the Index into the Pool for database items that are 
referenced via Handles; e.g.; Show Title entries. A database item's Handle is an 
index into the Handle Table. A database item's PooOndfex can change due to 
15 garbage collection in the Pool, but its Handle will not change as long as that item 

exists in the database. Items deleted from the database return their Handle to die top 
of the free list. 

Handle Table entry 0 is always the head of the J^Jist. The Table, is 
initialized to all free entries with each entry containing the" Index of the next entry. 
£° 7,16 s]z& ? f ^ Hand,e Table ,fa Mfs * e number of database items that can be 

kept in the Pool. Systems with various numbers of channels will require different 
Handle Table sizes. V ' ~ 

Field Description " 

25 Pool Index Index into the Pool for the first Pool Block containing the 

item. 

Database Show Schedule Access Overview 

The database show schedule access scheme is shown in Figure 28. The 
Channel Data is maintained in the Internal Database Engine data structure called the 
30 Channel Data Table. The Channel Data Table selects the channels accessed by a 

Region. The Channel Data Table is built by the system command processor from the 
Region Command and Channel Data Commands. The channel related information is 
extracted from the Region Command and placed in the Channel Data Table. 
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The Region Id to use is extracted from the authorization command. The 
Region Id is the key information for show schedule generation. The Region Id selects 
the Region Command processed by the subscriber unit, which defines the Channels 
Id accessed, which defines the Channel E>ata Table, which defines the Show Lists, 
5 which selects the Show Titles and Show Descriptions, which reference the Themes 
Categories and Theme Sub Categories. Once the Channel Data Table is defined, 
the Channels are referenced directly through the Channel Data Table. 

Each lower level table in the show schedule is accessed through a HANDLE. 
The HANDLE js translated by the Handle Table into a pointer in memory. 
10 Channel Data Table f 

As shown in Figure 29, the Channel Data Table contains information on each 

'A| * 

channel in the Region. This data is used; for access to the schedule data f Show 
Lists ) for a channel, tuning, display on the Channel Banner, for channel gliffs, and 
during Setup. Further details are provided in Table XXIII. 



15 Field 



pescriptioff 

Type/Nbr Blks Pool Enti£ Type and number of blocks required to 

hold this Pool item. The type value indicates that this 

j^r- ... is a 2 b^' field since the length can be^me very 

large due to the number of channels in the Region. 
20 Channel Data Table Type =1. v 

Nhr Channels Number of Channel Entries in the user's Region 

(including Jnaaive channels ). 
J "" , Table XXm * " 

Channel Entry ^ 

25 There is one Channel Entry (see also Figure 29) for each channel in the 

Region. Further details are provided in Table XXIV. 
FIELD DESCRIPTION 

Channel ID Channel's unique ID number assigned by the InSight 

Control Center. Used to distinguish Show Lists that 
30 the Subscriber Unit needs. 

Tune Channel Nbr Channel Number to be tuned to receive this channel's 

broadcasts.' Tune Channel Number may differ from 
the . original channel number if the channel is on a 
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Satellite Nbr 



Original Channel Nbr 



10 Signal Strength 



Data Pro Fig 



15 



Inact Fig 



■ • • • ■ ■ 



No Desc Fig 



20 



Name Fig 



25 



Name-Affiliation 



Mask Bits 



30 Favorite Link 
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cable system. E.g.; Channel 5 ( CBS ) might be 
broadcast on channel 17 on a cable network. 
Satellite Transponder Number, for acquiring Satellite 
broadcasts. 

Satellite Number, and Index used with the Satellite 
Codes to generate the specific commands for 
communicating with the satellite receiver box. 
Channel Number displayed in the channel gliff. This 
is the channel the user recognizes. : 
Signal Strength rating for the channel, acquired during 
Authorization scanning. Larger nurnbers represent 
stronger signals. 

Data Provider Flag. Identifies the channel we receive 

StarSight data from. Bit set during Authorization 

scan. J 

Inactive Channel Flag. This bit is set when the user 

specifies this channel as unwanted. When this bit is 

set no data is collected for the channel. 

No Descriptions Flag. Identifies, channels for which 

no description data is acquired. Set during user 

iSetup. • 

Flag indicating if channel icon should display the 

Original Channel Number or the first three characters 

from the 'Name-Affiliation* Field. 6 = use number, 

1 = use characters. 

Text string giving channel's name and (if appropriate) 
network affiliation; e.g., "KTVU : FOX". 
Bits which are set indicate which characters in the 
'Name- Afflilation' string are to be masked out. 
Channel ID Entry number for the next most favorite 
channel. Set During user Setup. Used when traversing 
this table in 'favorites' order. Very 1st entry will = 
02H. 
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Handle for this channel's Show List HandleTable. 



Handle for table of Duplicate Channels associated with 
this base channel. 
Table XXIV 
Channel Duplicates Table J 

The Channel Duplicates Table (figure 30) contains information on each 
channel in the Region that is the duplicate of a base channel. This data is used to 
adjust the display of Blocks of pay-for-view type channels. All of the channels share 
. a common base Channel Show List, r bjut add 4 sorting time to the offset of the base 
channel's Show List. The Base Channel ID is not stored in the structure. Instead 
the structure is referenced as a Handle|y the channel entry in the Channel Data 
Table. If a channel entry has duplicate channels, then the Duplicate Channel Handle 
fiejd has a Hapdle Number tp access t$e table by.. Further detrils are provided in 
Table XXV. 

Description 



Field 



< f 



Type/Nbr Blks 



Nbr Channels 



Pool Entry Typeand number of blocks required to hold this 
Pool item. The type value indicates that this is a 2 byte field 
since the length can become very large due to the number of 
channels in the Region. 

I^umbej of dupI^t^Channel eptrigs,in the user's region 
including ina^e channels). 

Table XXV 



Channel Duplicates Entry 

There is one Channel Duplicate Entry for each duplicate channel in the 
Region. Further details are provided in Table XXVI. 
Field Description 



Tune Chan Nbr 



Time Offset 



T •- 

Tuned Channel Number for the channel that duplicates the 
Show List of the base channel by some time offset (9 bits). 
This is the offset An minutes from the starting time of the Base 
Channel ID. 
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Table XXVI 

Show List Handle Table 

A ' Show List Handle Table' (Figure 31) contains Handles to Show Lists for every 
day of the week. This table is pointed to by the 'Show List Handle Table' Handle 
located in the Channel Data Table. Via this table we can access Show Lists 
representing a weeks worth of scheduling. Further details are provided in Table 
XXVII. 

Field Description 

Type/NbrBlks Pool Type = 40H, NbrBlks = 1. Since both pieces of 

. , . .. information are contained^ the 1st Byte, this value will 

equal 41H. 

' x 

Reference Count Number of times this Show List is referenced by another 

: \ ' ■ • •* : : - *f 

object in database. When this structure is initially created, 

Reference Count will = 1 since Channel Data Table makes 

15 reference to it. J; 

Monday - Sunday One Handle for every day of the week. These Handles point 

to actual 

Show List Handles Show Lists representing a given day of the week. Initially, 
and as necessary, when given Handle = 0000, means 
20 Show List is needed. ^' 

Table XXVII 

Show List r ' v ^ 

A Show List (Figure 32) contains 24+ hours of scheduling for a given 
channel. The only time it will in fact contain more than 24 hours of scheduling is 

25 when a program starts in the current day and crosses the 24 hour line while still 
broadcasting. AH Show Lists will always begin at the same time every day. A 
Dummy Slot will be created to deal with overflow from the previous day if 
necessary. For a complete set of scheduling, seven separate Show Lists are 
required for every Program Originator supported by given Subscriber Unit. 

30 Access to the Show List is via the Show List Handle Table for a given day of the 
week. Further details are provided in Table XXVIII. 
Field Description 
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Type/Nbr Blk 



Version 



Start Time 



10 



15 



Pool Entry Type and Number of Blocks required for the 
entry. Show List pool type = 02H 
The current Version of the Show List, allows us to recognize 
when a new Version of a Show List has arrived. 
Start Time ( in number of minutes since midnight January 
U 1992 - GMT ) for the First Show in the Show List. Used 
for determining new schedule days as they come in. 
Table XXVTTT 

Show Entry 

A Channel's schedule is given by an ordered sequence of Show; Entries. 
These Entries give a show's duration, title, and possibly an episode description; 
The entries are either 4 , 6, or 8 bytes lj>ng depending on whether the show has 
a description and/or Group ID. 

. ..?? ndil £ e . .entry that to a given start time requires } the Entries 

to be scanned, in order, from the beginning of the list and adding Duration values. 
There must be no gaps in the Show Lis^ Further details are provided in Table 
XXK. 
Field 

Dummy Flag 



Description 

Set if 1st slot Dyurnmy means last show of last Show List 



20 



15 



DID Flag 



Duration 



GRP Flag 



over. This much time contained in duration. 

.•A 



10 



SID Handle 



Description ID Flag. If this bit = 1 , then a DID Handle 
^J^ 1 !^ %M^U-e ; ^en^.is at least 6 jbytes long . 
and the show has ^ description. 

Length of progranv minutes - Range: 1 minute - 240 minutes 
( 4 hrs ). Shows Jonger than 4 hours must be broken into 
multiple parts with each part given a new slot. 
Group ID Flag. If this bit =1 then a Group ID field exists 
for this entry; i.e. entry is at least 6 bytes long and the show 
is a member of a Record Group. If DID Flag set entry, entry 
is 8 bytes long. 

Handle for the Show Title Entry that gives this Show's Title 
and Theme Category information. 
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DID Handle Handle for the Show Description Entry that gives this show's 

episode description and some additional Theme Category 
information. This field is only present if the 'DID Fig' field 
is set. f 

Group ID Value of the Group ID that is used by the Record Manager to 

identify shows that are members of a Record Group. 

Delimiters Prior to 1st show slot there will be an 'EEH' delimiter. 

Following last show slot, there will be an 'FFH' delimiter. 
Table XXIX 

Show Title . 

Show Titles (Figure 33) contain the usually compressed text of a Show's 
Title. There is one entry per unique Show Title. * 

Show Titles are Pool based items. An entry is created whenever a Show List 
j X is receded (for a channel die Subscriber Unit is collating data for) that contains _ 
an SID for which the Subscriber Unit does not already have jthe Show Title. When 
an entry is created a Handle is allocated to it and the 'Neei It' flag is set in the 
Show Title Handle Table Entry. 

The entry size is determined by the length of the titlf^ A single Pooi Block 



is reserved (containing a null title string) when a new SffirTs received in a Show 
List. The entry is filled when the appropriate Show Tide message is subsequently 



10 



■ 4 



5 



0 



received and the 'Need It* flag is then cleared. At that time, the entry may be 
relocated and expanded to multiple >ooI Blocks (but its Handle will stay the same) 
Further details are provided in Table XXX. 

.'•■'It. 

Description 

-V-"- 

Pool entry type and number of consecutive Pool blocks 
required for the entry. Show Title Pool Type = 5?H. 
Unique number associated with Theme Category Data for this 
show. This is an index into the Theme Category Data Table. 
Flag indicating if Show Title text is compressed or not. 
Sometimes compression actually lengthens the string, so this 
flag is used to suppress de-compression when compression 
was not needed. ( 0 = not compressed, 1 = compressed ). 



Field 

Type/Nbr Blks 
Theme ID 
Compressed Flag 
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CC Flag indicating if show is Closed Captioned. 0 = no, 1 = 

yes. 

Stereo Flag Indication if show is broadcast in Stereo. 0 = no, 1 = 

yes. 

5 BW/C Flag indicating if show is broadcast in Black and White or 

Color. 0 = Color, 1 - B & W. 
Reference Count Number of times this Show Title is referenced by a Show 
List, Record Queue entry, or other item in the database. 
When this field is 0 the entry and its corresponding Show 
10 Tide Handle Table entry, are candidates for deletion. 

Show Title Text string for the Show Name. Normally this string is 

compressed by Huffman encoding; however, if he 
"Compressed " flag is not set, the text is straight ASCII. 
Table XXX 

15 Database ^ Show Title Hash Table Access Scheme 

The database show title hash table access scheme is shown in Figure 34. 
Show Title Handle Table 

Show Title Handle Tables (Figure 35) are Pool based tables used to 

'•" , ; b ,>V' •>•--.;;'■ J- ' "• ■'>;">;:, - ■'■ • - "'■ ■ < *■? ■ 

determine if a^show title is needed or if it Has already been received. There is one 
- , , * ■ . ' ' ** , , v " ■ *.:■ 

20 Show Title Hindle Table for each possible value that an SID can Hash to; i.e., 256 

tables. 

A Show Title Handle Table entry ,is|nade for every unique SID received in, 
any Show List message for a channel that the SU is collecting data for. The 

r* " ' - % • 

particular table, that the entry is made in is determined by the SID's Hash value; that 
25 is, the SID's least significant 8 bits. 

These tables must be updated as SIDs are eliminated from the database. A 
Show Handle Table Walker background task is turned on and accesses these tables at 
regular intervals and checks them for Reference Counts that have gone to 0. The 
Walker looks for entries that can be deleted. Further details are provided in Table 



30 XXXI. 

Field Description 

Type Pool entry type for Show Title Handle Table = 03H. 

Nbr Blks Number of Pool Blocks required for the entry. 
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Nbr Entries Number of table Entries. Used when searching table for 

matching SID values. This can never be 0 . 
Table XXXI 

Show Title Handle Table Entry 
5 The Show Title Handle Table contains multiple entries. Each of these Entries 
contains the following field: 
Field Description 

Need It Flag Flag indicating if the Show Title text string message has been 

received for this SID. 0 = Show Title received, -1 = not 
10 received. 

Show Title Hash Table 

The Show Title Hash Table (Figure 36) is a fixed size, pre-allocated table 

containing only Pool indices for each possible SID Hash value. The SID Hash value 

is an index into this table. The value in the nth entry is an index into the Pool for 
15 the Show Title Handle Table containing all SIDs received so far that Hash to n. 

Further details are provided in Table XXXII. 

Field Description 

Pool Index Pool Index for the furst block of the Show Title Handle Table 

for SID's that hash to.this entries offset from the beginning of 
20 the table. A value of 0 means no SID's have been found so 

far (in Show Lists for channels we collect data for) that have 
Hashed to this entry. 
SID Unique Show ID number. Only the most significant 12 bits 

are stored since all entries in this table have the same least 
25 significant 8 bits. This 20 bit number is unique for each 

Show Title. 

Handle Index into the Handle Table which, in turn, gives the Pool 

Index for the first Pool Block containing the corresponding 
Show Title Entry. 
30 Table XXXII 

Show Description 

Show Descriptions (Figure 37) contain the (usually) compressed text of a 
show's episode description. There is one entry per unique show description. 
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Show Descriptions are Pool based items. An entry is created whenever a Show List 
is received (for a channel the SU is collecting data for) that contains a DID for 
which the SU does not already have the show description. That is, the 'need it' flag 
is set in the Show Description Handle Table entry. 
5 The entry size is determined by the length of the description. A single Pool 

block is reserved (containing a null description string) when a new DID is received 
in a Show. List. The entry is filled when the appropriate Show Description message . 
is subsequently received and the 'need it' flag is cleared. At that time, the entry 
may be relocated and expanded to multiple Pool blocks (but its handle will stay the 
10 same). Further details are provided in Table XXXm. 
Field Description 

Type/Nbr Blocks Pool entry type and number of consecutive Pool blocks 

required for the entry. Show Description Pool Type = 6?H 
Cmp Fig Flag indicating if show description text is compressed or not. 

15 Sometimes compression actually lengthens the string, so this 

flag is used to suppress decompression when compression was 
not needed. (0 = not compressed, 1 = compressed). 
Flag indicating if the show episode is close captioned. 0=no, 

Flag indicating if the show episode is broadcast in stereo. 
0=no, 1 =yes. 

Flag indicating if the show episode is in black & white or 
color. 0=color, 1=B&W. 
Rating Pig Flag indicating if rating bytes are present. 0 = no, 1 = yes. 

Critics Rating Number of star's accorded the show by the critics. 0=no 

rating. 

MPAA Rating Audience suitability rating. 0=G, 1=NR, 2=PG, 

3=PG13, 4=R,5=X, 6=NC17. 
Traits Bit Mask Bit mask indicating show's attributes such as violence or 
profanity. See 'Show Description Command' for bit 
assignments. 



CC 



Stereo 



BW/C 
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Bit 


Attrihntp 

jTVIIL 1UUIC 


o 


nrofianitv 


1 


niifiitv 

IIUUHY 


? 


V IU1CUUC 


3 


adult Qitiiatinn 


4 


adult thpmpQ 

uUUll UlwIll&O 




milH \itrk\(*r\/-e± 
11111U VlUldluC 


6 


brief nudity 


7 


adult language 


8 


mature themes 


9 


not used 



Reference Count Number of times this show description is referenced by a 

Show List, Record Queue entry, or other item in the database. 
15 When this field is 0 the entry and its corresponding Show 

Description Handle Table entry are candidates for deletion. 
Theme ID Unique number associated with Theme category data for this 

episode of the show. This is an index into the Theme 

Category Data Table. 

20 Show Description Text string for the show name. Normally this string is 

compressed by Huffman encoding; however, if the 
'compressed' flag is not set, the text is straight ASCII. String 
is null terminated. 

Table XXXIII 
25 Database Show Description Access Overview 

Figure 38 depicts the database show title hash table access scheme. 
Show Description Handle Table 

Show Description Handle Tables (Figure 39) are Pool based tables used to 
determine if a Show Description is needed or if it has already been received. There 
30 is one Show Description Handle Table for each possible value that an DID can Hash 
to; i.e., 256 Tables. 

A Show Description Handle Table entry is made for every unique DID 
received in any Show List message for a channel that the SU is collecting data for. 



WO 95/31069 PCTAJS95/05169 

95 

The particular table that the entry is made in is determined by the DTD's Hash value; 
that is, the DID's least significant 8 bits. 

These tables must be updated as DIDs are eliminated from the database. A 
Show Handle Table Walker background task is turned on and accesses these tables 
5 whenever 5 DIDs have been deleted; i.e. their Reference Counts have gone to 
L The Walker looks for entries that can be deleted. Further details are available in 
Table XXXIV. 

Field Description 

T yP e Pool entry Type for Show Title Handle Table = 04H 

10 Nbr Blocks Number of Pool Blocks required for the entry. 

Nbr Entries Number of Table Entries. Used when searching table for 

matching DID values. 

Table XXXIV 
Show Description Handle Table Entry 
15 The Show Description Handle Table contains multiple entries. Each of these 

entries contains the fields shown in Table XXXV: 
Field Description 

Need It Flag Flag indicating if the Show Description text string message 

has been received for this DID. 0 = Show Description 
20 received, 1 = not received. 

DID Unique Description ID Number. Only the most significant 8 

bits are stored since all entries in this table have the same 
least significant 8 bits. This 16 bit number is unique for each 
Show Description. 

25 Handle Index into the Handle Table which, in turn, gives the Pool 

Index for the first Pool Block containing the corresponding 
Show Description entry. 

Table XXXV 

Show Description Hash Table 
30 The Show Description Hash Table (Figure 40) is a fixed size, pre-allocated 

table containing only Pool indices for each possible DID Hash value. The DID 
Hash value is an index into this table. The value in the nth entry is an index into the 
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Pool for the Show Description Handle Table containing all DIDs received so far that 
Hash to n. Further details are as follows: 
Field Description 

Pool Index Pool Index for the first block of the Show Description Handle 

Table for DID's that Hash to this entries' offset from the 
beginning of the table. A value of 0 means no DID's have 
been found so far ( in Show Lists for channels we collect 
data for ) that have Hashed to this entry. 

Theme Category Table 

The Theme Category Table (Figure 41) contains the definition of the Themes 
downloaded to the Subscriber Unit. The Themes Categories are used to search for 
shows of a particular type. Each Theme Category contains one or more Theme 
Subcategories. Each Theme Category in the Theme Category Table has a Theme 
Subcategory Table associated with it. Further details are provided in Table XXXVI. 
!5 Field Description 

Type/Nbr Blks Pool entry type and Number of Blocks required to hold this 

Pool item. The type value indicates that this is a 2 byte field 
since the length can become large due to the number of 
possible Theme Categories. 
20 Reference Count Number of times this table is referenced. Initialized so the 

garbage collector does not delete it. 
Version Version Number of the Theme Category Table New 

Categories and Sub Categories are collected when the 
Version Number changes. New Theme Counts must be also 
25 be determined. 

Nbr Theme Categories Number of Theme Category Entries. 

Table XXXVI 

Theme Category Entry 

There is one Theme Category Entry for each Theme Category. Further 
details on the Theme Category Entry are provided in Table XXXVII. 
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Field 



Description 



Theme Category ID 



0 



5 



Theme Subcategory 

Table Handle 

Theme Category 

Name Length 
Theme Category 
Name 



The Theme Category's Unique ID assigned by the 
Head End. Used to Identify Theme Subcategories for 
this Primary Category. 

Hie Handle to the Memory Pool Block containing the 
Thane 

Subcategory Table that corresponds to this Theme 
Category. ., 

The length of the text string in bytes. Used to locate 
the start 

of the next entry. 

Compressed text name of Theme Category. Huffman 
encoded. 

Table XXXVII 

Theme Subcategory Table 

The Theme Subcategory Table (Figure 42) contains information about 
Theme Subcategories contained in a Theme Category. Each Theme Subcategory 
Table is referenced by one Theme Category Entry. Each Theme Subcategory Entry 
contains a name, qualifiers, and Theme Indexes. The Theme Indexes in Show Titles 
and in Show Descriptions are matched against the Theme Indexes in a Theme 
Subcategory. Theme Indexes that match identify which shows are a members of a 
Theme Subcategory. Further details are provided in Table XXXVEI. 
Description 

Pool entry Type and Number of Blocks required to hold this 
Pool item. The Type value indicates that this is a 2 byte field 
since the length can become very large due to the number of 
Theme Subcategories in the Theme Category. 
Theme Category ID of owning Theme Category. 
Number of times this object is Referenced. 



Field 

Type/Nbr Blks 



Theme Category ID 
Reference Count 



Nbr Theme 



Number of Theme Subcategory Entries in the Theme 
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Subcategories Category . 

Table XXXVm 

Theme Subcategory Entry 

There is one Theme Subcategory Entry for each channel in the Region. 
5 Further details on the Theme Subcategory Entry are provided in Table XXXDC. 
Field Description 

Subcategory Show Count of shows that reference this Subcategory. A Show 
Count Title/Description pair should only be counted once. 

Entry Length Total remaining Entry Length in Bytes ( Indexes & Text ) 

10 Nbr Theme Indexes Number of Theme Indexes that reference tjhis Theme 

Subcategory. 

Theme Index [ ] Theme Indexes, ( 9 bits + Nbr extra Theme Index Bits ) 
long. This is implementation dependent. The Head End tells 
the Subscriber Unit how many bits are required for the largest 
15 Theme Index. The default is 9 bits. The Subscriber Unit 

can encode those as 9 bit values, or as 16 bit values. 
Subcategory Name Compressed Text Subcategory Name. 

Table XXXIX 

20 This section describes the messages sent between all processors in a 

subscriber unit 52. All messages are described even though some subscriber unit 

implementations may not use or require all of the messages. 

Diagrams are given showing the format of the messages followed by a 

description of each of the fields in the message. Greyed fields represent currently 
25 unused fields, but the bits in these fields should be set to 0's in order to maintain 

compatability with future implementations. All fields are binary, 2*s complement 

numbers unless otherwise noted. 

Database Engine - I/O Processor Interfaces 

The Database Engine and the I/O Processor communicate via an IM bus 
30 running at 1 Mbits per second. The I/O Processor receives Data Transmission 

Network data via one or more specified Vertical Blanking Interval line(s) and 

transmits the acquired raw bytes when requested by the Database Engine Processor. 
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The Database Engine controls the tuned channel and specifies the particular VBI 
line(s) to be used. 

The Database Engine also issues graphic display commands to the I/O 
Processor such as fill a rectangle with a given color, and save or restore the pixel 
5 contents of a given rectangle on the screen. All subscriber unit screens are 
constructed from these graphic display commands. 

The Database Engine issues commands to the I/O Processor in a packet 
(Figure 43) that contains a packet length field followed by one or more commands. 
TTie I/O Processor transfers all packet bytes to a RAM command buffer and, at the 

10 completion of the transfer, begins executing die commands in die order they were 
received in the packet. The I/O Processor sets a status flag indicating that it is busy 
until all commands have been executed. Packet size is always the first two bytes 
received in any command sequence issued to the I/O Processor. Only one command 
packet can be sent to the I/O Processor at a time. 

15 Graphics Commands 

The following commands define the primitive graphics operations needed to draw 
system display screens on a television set connected to or incorporating the 
subscriber unit 52. 

Screen coordinates are based on (0,0) being in the upper left corner of the 
20 screen. The TPU 2740 allows X coordinates as high as 503 but the system's 

maximum X coordinate is 251. This allows the system to keep X coordinates in a 
single byte and to have two pixels of different colors comprise a 'system pixel'. 
Hence (251,207) is the lower right corner of the screen and X coordinates received 
in commands must be doubled by the 2740. 
25 All colors in the following commands are comprised of two basic TPU 2740 

colors in the upper and lower nibbles of the color byte. Using two separate colors in 
a single system pixel enhances the number of colors that can be shown. Setting a 
system pixel actually involves setting two successive 2740 pixels along the X axis 
using the two colors in the color byte. 
30 When areas are filled, the colors must be dithered. That is, the colors used 

for successive 2740 pixels along the X axis must alternate between the two colors 
given in the appropriate command color byte. Even rows start with color 1 while 
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odd rows (i.e. Y coordinate is an odd number) start with color 2 and alternate 
between the two colors for successive pixels along the X axis. 

The 2740's graphics routines clip output if the X or Y coordinate exceeds the 
limits of the screen. That is, graphics do not wrap if the coordinates of an operation 
5 go outside (0,0) to (251 ,207). 

Commands with illegal parameter values are ignored. An illegal 'cmd type' 
field causes all subsequent commands in the packet to be ignored; that is, the IOP is. 
finished with a packet if it ever detects an illegal command type. 



10 Set Graphics Defaults 

The Set Graphics Defaults command (Figure 44) causes the I/O Processor 
(IOP) to reset all its graphics variables to their initialization values. This command 
is used when the Database Engine has come up from a power on reset state. The 



Graphics commands take precedence over VBI processing. 



IOP initializes these values to: 



15 



o shadow width = shadow height = 3 
° shadow color = BLACK 



° small font delta X 



6 



o small font delta Y 



10 



20 



° large font delta X = 
° large font delta Y = 
o highlight = WHITE 
° underlinel = GREY 



8 



15 



30 



25 



o underlined = BLACK 
Further details are provided in Table XXXX. 
Field Description 

cmd type Command ID number = 1 identifying this as a Set Graphics 

Defaults command. 

shadow width Number of pixels along the X axis for vertical shadows. 

Used by Draw Rectangle command, 
shadow height Number of pixels along the Y axis for horizontal shadows. 

Used by Draw Rectangle command, 
shadow color 1 9 2 Default colors to be used for shadows. 
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10 



15 



20 



25 



30 



small font delta X 



small font delta Y 



large font delta X 
large font delta Y 



Number of pixels spacing along X axis for small font 
characters. Used by Write ASCII String command. 
Number of pixels spacing along the Y axis allowed for text 
lines written in small font characters. This value is added to 
the Y coordinate for the current text line when a carriage 
return character is encountered in a text string by the Write 
ASCII String command. 

Number of pixels spacing along X axis for large font 
characters. Used by Write ASCII String command. 
Number of pixels spacing along the Y axis allowed for text 
lines written in large font characters. This value is added to 
the Y coordinate for the current text line when a carriage 
return character is encountered in a text string by the Write 
ASCII String command. 

Color ID numbers for the top embossing lines and left side 
lines. 

Color ID numbers for the inner embossing underline and inner 
right side line. 

Color ID numbers for the lowest embossing underline and 
outside right verticle line. 

Table XXXX 

Erase Screen 

The Erase Screen command (Figure 45) causes the I/O Processor to blank the 
screen and set all display buffer pixels to the specified "transparent" color. Further 
details are provided in Table XXXXI. 



highlightl,2 
underline 11,12 
underline 21,22 



Field 
cmd type 

xpar color 



Draw Rectangle 



Description 

Command ID number = 2 identifying this as an Erase Screen 
command. 

Color ID number to be used for transparent pixels. Only the 
lower nibble is used in defining the transparent color. 
Table XXXXI 
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Draws a rectangle of specified dithered colors. Rectangle can be filled, 
outlined, shadowed, and/or embossed in a single operation based on the 
corresponding flag bits set in the command. Each of these operations can be done 
independently of the other operations. For example, an empty rectangle can be 
drawn by setting only the 'outline' flag bit. 

For solid color, filled rectangles, both 'fill colorl' and 'fill color2' should be 
the same value. Rectangles should be filled, then embossed, outlined and shadowed . 
in that order. Further details are provided in Figure 46 and Table XXXXEL 



Field 
cmd type 

upper left X 

upper left Y 

width 

height 

fill colorl, 2 

outline colorl ,2 

fill 

outline 
shadow 



emboss 



Description 

Command ID number = 3 identifying this as a Draw 
Rectangle command. 

X coordinate for the upper left corner of the rectangle. 

Y coordinate for the upper left corner of the rectangle. 

Rectangle size in pixels along the X axis. 

Rectangle size in pixels along the Y axis. 

Color ID numbers for the dithered colors used to fill the 

rectangle. Only used if Till 5 bit is set. 

Color ID numbers for the dithered colors to be used for the 

outline around the rectangle. Not used if 'outline* flag = 0. 

Flag indicating if rectangle should be filled with dithered 

colors. 0 = no, 1 = yes. 

Flag indicating if rectangle should be outlined. 0 = no 
outline, 1 = outline rectangle with 'outline' color. 
Flag indicating if rectangle should have a shadow. If the 
shadow bit is set for drawing a pop-up then save and restore 
rectangle operations must account for the size of the shadow. 
Shadow size and color are set by the Set Graphics Defaults 
command. 0 = no shadow, 1 = draw shadow. 
Flag indicating if rectangle should be embossed to give a 3D 
effect. Embossing colors used are determined from the Till - 
color r and 'fill color 2' fields. 0 = no embossing, 1 = do 
embossing. 

Table XXXXTT 
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Example rectangles are shown in Figures 47A-47E. 
Save Rectangle 

Causes the pixel contents of a specified rectangle on the screen to be saved in 
a temporary buffer for later restoration via a Restore Rectangle command. Further 
5 details are provided in Figure 48 and Table XXXXIII. 
Field Description 

cmd type Command ID number = 4 identifying this as a Save 

Rectangle command, 
upper left X X coordinate for the upper left corner of the rectangle. 

10 upper left Y Y coordinate for the upper left corner of the rectangle, 

width Rectangle size in pixels along the X axis, 

height Rectangle size in pixels along the Y axis, 

pop-up ID ID number assigned by the command initiator (value is 

equivalent to nesting level). This field is only used for 
15 debugging. 

Table XXXXm 

Restore Rectangle 

Restores a rectangle to the screen that was previously saved with a Save 
Rectangle command. Rectangle to be restored is recognized by its 'pop-up ID* field. 
20 Restoration coordinates allow a previously saved rectangle to be brought back at a 
different place on the screen, such as when moving a cursor or icon of some sort. 
Further details are provided in Figure 49 and Table XXXXIV. 
Field Description 

cmd type Command ID number = 5 identifying this as a Restore 

25 Rectangle command. 

upper left X X coordinate for the upper left corner of the rectangle, 

upper left Y Y coordinate for the upper left corner of the rectangle. 

save Flag indicating if rectangle's storage area can be released for 

use by subsequent save operations. If the 'save' flag is set 
30 then another 'restore' operation can be performed without 

doing a corresponding 'save'. 0 = release, 1 = save, 
pop-up ID ID number previously assigned to a saved rectangle. Not 

used except for debugging. 



10 
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25 
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Table XXXXIV 

Move Rectangle Vertically 

The Move Rectangle Vertically command (Figure 50) causes the pixel 
contents of a specified rectangle to be copied to another place in display memory, 
effectively moving the rectangle on the screen. Only vertical moves are handled by 
this command. Rectangles are scrolled up or down one line at a time until the 
specified scroll size has been achieved. Further details are provided in Table 
XXXXV. 

Description 

Command ID number = 6 identifying this as a Move 
Rectangle Vertically command. 
X coordinate for the upper left corner of the rectangle. 
Y coordinate for the upper left corner of the rectangle. 
Rectangle size in pixels along the X axis. 
Rectangle size in pixels along the Y axis. 
Number of pixels to shift the rectangle per move operation. 
Negative numbers mean shift the rectangle to a position 'scroll 
size' pixels higher on the screen. Positive numbers mean shift 
the rectangle lower on the screen. 

Number of horizontal sync pulses to count before starting the 
next single line scroll operation. Provides some scroll rate 
control for the Database Engine. 
Table XXXXV 

Write ASCII String 

Output an ASCII string to the screen. Starting coordinates for the first 
character of the string correspond to the character's upper left corner. Successive 
characters are on a horizontal line until an ASCII carriage return character is 
encountered; subsequent characters are output 'delta Y' (as specified in the Set 
Graphics Defaults command for each font) pixels lower on the screen and restarting 
at the original X coordinate. Illegal characters cause a to be output in their 
place. 



Field 
cmd type 

upper left X 
upper left Y 
width 
height 
scroll size 



20 delay 
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Characters can be output in one of two fonts. Only upper case characters are 
supported in the large font. Further details are provided in Figure 51 and Table 
XXXXVL 

Description 

Command ID number = 7 identifying this as a Write ASCII 
String command. 

Identifies which of two fonts should be used for each 
character in the string. 0= small font, 1 = large font. 
X coordinate for the upper left corner of the first character in 
the line. 

Y coordinate for the upper left corner of the first character in 
the line. 

Color ID numbers for the pixels that form characters. (Only 
the lower nibble is used - characters are not dithered.) 
String of ASCII characters to be output. Output stops when a 
NULL is found. 

Table XXXXVT 

Draw Channel Icon 

Draws a channel icon at specified coordinates. Coordinates for the icon 
represent the upper left corner of a rectangle that would exactly contain the icon if it 
held a 1 or 2 character channel name These coordinates must be adjusted if the 
'ASCII channel name* field is longer than 2 characters In this case, the IOP must 
decrement the X coordinate sent in the command by 3 * (channel name length-1). 
An empty channel icon is drawn if the channel name string has no characters in it 
(i.e., an empty icon of 1-2 character size if byte 5 = 0). Further details are 
provided in Figure 52 and Table XXXXVH. 



Field 
and type 

font 

start X 

start Y 

text color 1,2 

ASCII string 



Field 
cmd type 

upper left X 
upper left Y 
fill color 1,2 



Description 

Command ID number = 8 identifying this as a Draw 

Channel Icon command. 

X coordinate for upper left corner of the icon. 

Y coordinate for upper left corner of the icon. 

Color ID numbers for the fill colors inside the channel icon. 
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text co!orl,2 Color ID numbers for the text in the channel icon and for the 

outline of the icon. 

ASCII chan name 0 to 4 characters to be used for labeling inside the channel 
icon. May be a name such as "SHOW", "G3-24", 
' "RESET", "CNN" or a channel number such as "7" or "135". 

Field has a NULL terminator; i.e. byte = 0 after last 
character of the name. If this string is of length 0 (i.e. first . 
byte of this field = 0) then an empty icon is drawn. 
Table XXXXVn 
Examples of channel icons are shown in Figures 53A-53C. . 
Disable Transparent Color 

The Disable Transparent Color command (Figure 54) specifies that no color 
code number represents transparent pixels. This command is used to indicate when * 
no color should be transparent and should be sent each time a full screen display is 
15 drawn. Further details are as follows: 
Field Description 

cmd type Command ID number = 9 identifying this as a Disable 

Transparent Color command. 
Network Data Acquisition and Control Interface 

20 System data is received via the PBS network, MTV, Showtime or other 

transmission source on one or more Vertical Blanking Interval (VBI) lines. The I/O 
Processor acquires data from each line (if there are multiple lines) and stores it into 
separate input buffers. Data is stored in the IOP's input buffers even if the framing 
code is bad for a given field. In this case, two bytes of 03s are stored. The data is 

25 only transferred to the Database Engine Processor if the command packet contains at 
least one command that requires a response. 

When responding to a Database Engine request, the I/O Processor transfers 
as many bytes as it can that is less than or equal to the number of requested data 
bytes. If an input buffer becomes full, the I/O Processor begins dumping the data 

30 until the buffer is emptied or a reset is issued. A full buffer causes the 'ovfl' flag to 
be set in the next response it sends to the Database Engine. 

The I/O Processor can handle up to 2 VBI lines of system data or one line of 
system data and closed caption data from line 21. Data is always acquired from both 
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fields for each system data VBI line. Closed caption data is also acquired from both 
fields. 

The I/O Processor responds within 10 milliseconds to any command that 
requires a response. 
5 Stop VBI 

The Stop VBI command (Figure 55) causes the I/O Processor to initialize its 
internal variables related to VBI processing; All VBI buffer counters are cleared and. 
any acquired data is lost, VBI data acquisition is stopped until a Set VBI Control 
Parameters or a Flush VBI Buffer command is received. Further details are as 
10 follows: 

Field Description 

cmd type Command ID number = 16 identifying this as a Stop VBI 

command. 

Set VBI Control Parameters 
15 The Set VBI Control Parameters command (Figure 56) allows the Database Engine 

to specifiy parameters that control the acquisition of VBI data. This command (or a 

Flush VBI Buffer command) must be issued after a Stop VBI command in order to 

enable VBI data acquisition. 

Parameters must be sent for all VBI lines (maximum of two lines). Each 
20 new Set VBI Control Parameters command replaces all previous parameters. 

Parameters must be ordered by line number with the lowest VBI line first. Further 

details are provided in Table XXXXVm. 



Field Description 

cmd type Command ID number = 17 identifying this as a Set VBI 

25 Control Parameters command. 

nbr lines Number of VBI lines to use for acquiring system data. 

VBI line 1 Primary VBI line number whose data is to be acquired. 

fram code 1 Framing code to be used for VBI line 1 . 

rate 1 Data rate for VBI line 1. 0 = Telecaption rate (2 bytes per 

30 line), 1 = fiill rate (33 data bytes per line). 

VBI line 2 Additional VBI line numbers (if any) whose data is to be 



acquired. Not present if only one VBI line to be processed. 
Maximum of 2 VBI lines. 
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rate 2 Data rate for VBI line 2. Not present if 'nbr lines' field = 

1.0 = Telecaption rate (2 bytes per line), 1 = full rate (33 
data bytes per line). 

fram code 2 Framing code to be used for VBI line x. Not present if 'nbr 

5 lines' =1. 

Table XXXXVin 

Read VBI Status 

The Read VBI Status command (Figure 57) causes the I/O Processor to 
return status information on the specified VBI line buffer. Further details are 
10 provided in Table XXXXK. 

Field Description 

cmd type Command ID number =18 identifying this as a Read VBI 

Status command. 

VBI line VBI line number whose status is being requested. =0 means 

15 return status for all active VBI lines. 

Status returned is formated as shown in Figure 58 and further described in Table L: 
Field Description 

VBI line VBI line number whose status is being returned. 'VBI line' 

= 0 means a status request was made for a VBI line that the 
20 IOP is not collecting data for; i.e., an illegal VBI line number 

was received in the command that generated this response. 

(Lines for which data is collected are set with a Set VBI 

Control Parameters command.) 
nbr unread bytes Number of data bytes in buffer for 'VBI line' that have not 
25 yet been read by the Database Engine. A value of 255 for 

this field indicates that the IOP has at least 255 bytes 

available. 

ovfl Flag indicating VBI buffer has overflowed since last read 

request (i.e., I/O Processor had to drop some VBI data since 
the buffer was full of unread bytes). 0 = no overflow, 1 = 
overflow occurred. 

rate Data rate for this VBI line. 0 = Telecaption rate, 1 = full 

rate. 
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Table L 

Read VBI Buffer 

The Read VBI Buffer command (Figure 59) causes the I/O Processor to 
return a specified number of data bytes from the buffer for the specified VBI line. 
5 Data is returned in first in, first out order. The number of data bytes actually 

returned will be less than or equal to the requested number of bytes. Further details 

are provided in Table LI. 

Field Description 

cmd type Command ID number = 19 identifying this as a Read VBI 

10 Buffer command. 

read again Flag indicating that the last Read VBI Buffer command should 

be repeated using the same parameters in effect at that time 
(i.e. repeat the last Read VBI Buffer command). If this bit is 
set then the 'VBI line' and *nbr bytes' fields will not be 
15 present in the command. 0 = read using parameters specified 

in this command, 1 = read using last specified parameters. 

VBI line VBI line number whose data is being requested. 

nbr bytes Maximum number of data bytes to be returned. If more bytes 

are requested than exist in the buffer then the number in the 
20 buffer will be returned. If die buffer is empty then a single 

byte VBI Data Response is returned (i.e., only byte 0 in 
Figure 60) indicating that no data is available. 

Data returned has the format of Figure 60. Further details are provided in Table 

LII. 

25 Field Description 

err fig Flag indicating if an error occurred since the last VBI access 

command. Database Engine should do a Read VBI Status to 
get error information. 0 = no error occurred, 1 = had error 
since last VBI access. The error flag is not cleared until a 
30 Read VBI Status command is done. 

VBI line VBI line number whose status is being returned. 

data byte Successive data bytes from^the buffers for the given VBI line. 

Bytes are returned in first in, first out (FIFO) order. Number 
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of bytes returned will be less than or equal to the number of 
requested data bytes. No data bytes are returned if the buffer 
is empty. 

Table LII 

5 Flush VBI Buffer 

The Flush VBI Buffer command causes the I/O Processor to either transfer 
all existing data in a given VBI buffer or to reset VBI processing for a given VBI 
line without stopping data acquisition. VBI processing is re-enabled with the 
parameters sent in the last Set VBI Parameters command. This command re-enables 
10 VBI processing that had been suspended due to a Stop VBI command. 

If data is transferred then it is returned in the same response format as for a Read 
VBI Buffer command. Further details are provided in Table Lin. 
Field Description 

cmd type Command ID number = 20 identifying this as a Flush VBI 

15 Buffer command. 

c,r fl 8 Flag indicating whether remaining data should be transferred 

or not. 0 = don't transfer remaining data - just reset both 
buffers, 1 = transfer any existing data (up to 255 bytes) and 
then reset both buffers. 
20 VBI line VBI line number that is being flushed. 'VBI line' = 0 

means flush all VBI buffers. This field is ignored if non-zero 
and in concatenated VBI data transfer mode. 

Reception Groups 

25 A Reception Group (or RG) is a named entity which has an associated 

Channel Lineup. There are three broad categories of Reception Groups: Broadcast, 
Cable and Satellite. Examples of these are shown in Table UV: 
Type of RG Name Description 

Broadcast: "SF BAY" all channels receivable via VHF or UHF 

antennas in the San Francisco Bay Area 
Cable: " TCI > Fremont, all channels receivable by subscribers to the 

CA" TCI Fremont cable system 

Satellite: "TVRO North all channels receivable in North America via 
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America" Home Satellite antenna 
Table LIV 

Some RGs, and certainly Cable RGs, will have information associated with 
them which is of interest, and may be helpful in marketing and other operations. 
5 Some examples of such information are: 
Name of Contact 
Telephone Number 
FAX Number 
ADI 
10 DMA 

Each StarSight Subscriber Unit is considered to be a "member", so to speak, 
of one and only one RG. When it is first put into operation, the SU must be 
informed as to which RG it is in, so that it will display the Lineup which is true for 
that RG. 

15 Lineup Explanation 

A Lineup is the actual list of channels that are received in a particular RG. In 
fact at any given time, there is a one-to-one mapping of RGs and active Lineups: for 
every RG there is one and only one active Lineup, and for every active Lineup there 
is one and only one RG. It is possible that two RGs could sometimes have identical 

20 lists of channels received; it is equally possible that one list could be changed while 
the other does not. For this reason, each Lineup is RG-specific. A Lineup can 
usually be thought of as a description of information that could be obtained by 
viewing a physical geographic map (a map that shows coverage of TV stations and 
cable systems, that is); it contains information about which channels are available in 

25 the physical area that the Lineup covers. The purpose of a Lineup is to define what 
channels in a given RG need to be supported with data. 

Because of the well defined physical area of cable TV and broadcast TV, the 
viewable channels that a TV viewer located in that area would be able to receive are 
well known. These channels make up a Lineup, which is required so as to know 

30 what listings data to transmit for a given RG. 

It is possible for multiple LINEUP maps to cover the same area or overlap. 
An example of this might be two neighbors with one receiving TV via a home 
antenna and the other getting his from cable. In this case the cable subscriber would 
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be in a different RG than his non-cabled neighbor since he would be receiving more 
/ different channels from his cable. In the above case the StarSight data destined for 
both RG's is delivered from one PBS station and each SU listens for the data defined 
in its SU Lineup. 

5 In the case of broadcast TV a given RG could contain from one to dozens of 

channels and could include weak stations that are found in the fringe areas. In the 
case of a cable system the Lineup is very well defined and is the same for all 
subscribers in that cable system. The Lineup for satellite viewers is fairly constant 
for all viewers throughout the USA with the possibility of some differences between 
10 the east coast and the west coast but is more likely to be just one group covering all 
of the continental USA. 
File Layout Specifications 
Station List 

The Station List is made up of records with each record identifying and 
15 describing the essential characteristics of one broadcast station or satellite feed. 

To deal with unedited stations or repeater stations, a field is used to specify 
where, if anywhere, the station's schedule information is obtained. If the station is 
not currently edited, the value in this field is set to zero; if the schedule information 
is being provided using a different Station ID (in other words, this station is a 
20 repeater), then this field will contain the ID of the other station; if the station is 

handled normally (schedule is edited and data is provided under this ID), this field is 
left empty. 

The Station List is required to contain an entry corresponding to every station 
or feed for which the vendor supplies data to StarSight, regardless of whether that 

25 feed is present in any Lineup supplied by the vendor to StarSight. This is because 

StarSight sometimes identifies a need for data for a station, due to a show or test. In 
a case like this StarSight might internally generate a lineup containing this station, 
and just ask the vendor to supply the schedule information. 

In general, the vendor should be supplying data to StarSight for all regularly 

30 scheduled stations and feeds in the USA, as well as certain designated 

local-origination feeds; the Station List must contain an entry identifying each one of 
these, an entry for each alias for any of these, and an entry for every feed which 
appears in any lineup supplied by the vendor to StarSight. 
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Other fields give the station Call Letters or satellite feed's name, the usual 
abbreviation for the name, effective date and expiration date (for dealing with Call 
Letter changes). 
Lineup List 

5 The Lineup List is made up of two types of records: 
RG Records 

Each RG record explains the details about one RG, such as contact names, 
location, type of service, daylight saving time observed etc. 
Lineup Records 

10 Each Lineup record describes one of the channels received by the RG. The 

union of all the currently-effective records describing channels in a given RG 
comprises the Lineup for that RG. There may also be records which are not 
currently effective, either because the date they become effective is in the future, or 
because the date on which they ceased to be effective is in the past. Each record 

15 contains sufficient information to unambiguously identify the RG and channel it 

applies to, and (along with knowledge of the current date) to determine whether or 
not it is currently effective. It also contains information which allows the 
construction of composite channels. 

The Lineup List can be updated incrementally by transmitting a Lineup List 

20 Update, consisting of only the Lineups for RGs that have been modified since the 
last time the full Lineup List was transmitted. Note that any time a given RG's 
Lineup is updated, it must be updated in full; that is: a Lineup List Update may 
update only some of the RGs, but any RG which has its updated must be updated by 
transmitting all the lineup information for that RG. 

25 Probable usage would be for the full Lineup List to be transmitted weekly, 

and a Lineup List Update, transmitted daily. 
File Naming Conventions 

Filenames for the Station and Lineup lists shall be assigned as follows: 
Base name of each file shall consist of six characters signifying year, month and day; 

30 basename shall be separated from a suffix by a period, and the suffix shall denote 
which type of file, according to Table LV below: 
Basename.Suffix Type of File Examples 
yymmdd.STD Station List Daily file 940130.STD 
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yymmdd.LUW Lineup Weekly file 940519.LUW 

yymmdd.LUD Lineup List Update 941121.LUD 

yymmdd.TRD TVRO Lineup File 931225.TRD 

Table LV 

5 File content 

These files will contain records made up of ASCII text in the range of 20 to 
7E hex inclusive. The only exception to this is the end of record terminator OA hex, . 
an ASCII Line Feed. 
File Transfer 

10 The Station and Lineup files are pipe-delimited-format(PDF) ASCII files 

comprised of newline-terminated records. These files are to be transferred to 
StarSight electronically. 
Composite Channels 

The issue of composite channels is handled through the Lineup. If a single 
15 tunable channel routinely airs programming from more than one programming 
source, it is then known as a composite channel. (Example: A cable channel #41 
might show VH1 for part of the day and HBO for another part of the day, etc.) 

The Lineup will deal with this by assigning each of the feeds that go into die 
composite to die same "tune" channel. The start and stop times can then be used to 
20 determine what data to compile for that composite. 

Composite channels are seldom seen on broadcast TV or on Satellite TV but 
are quite normal for a cable provider. 
Station List 

Each record in the Station List file is comprised of the fields defined in Table 
25 LVL Each field is delimited from the next with an ASCII "pipe" (7C hex) character. 
Fields with a specified default size of 0 may be left empty if no data is available; 
fields with a nonzero minimum size are mandatory. Note: to inform StarSight that an 
entry of the Station List is being deleted, a Station List record is transmitted 
containing data in the the "Station ID" and "Last Modified Date/Time" fields, with 
30 all other fields empty. This signals StarSight to stop doing the internal processing 
associated with this Station. 
Station List Record Format 
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Field Name Field Size ' 
MIN MAX 
Station ID 12 12 



Station Type 



Call Letters or Feed 0 
Name 



Usual Abbreviation of 1 
Name 



Explanation of Name 0 



Native Channel 0 



120 



13 



Description 

The 12 digit LD. 
number of this Station 
or feed. 
0=Full Power 
Broadcast 

1 =Low Pwr TV Station 

2=Satellite Feed 

3 = Locally-originated 

4=other 

5=unknown 

Call Letters or usual 

name (must fit in 8 

characters!): 

e.g.,HBO-WEST 

(applies mostly to 

satellite feeds: must fit 

in at most 4 characters!) 

e.g. HBO 

Fully-descriptive name 
of the feed (generally 
applies to satellite 
feeds). 

Leave empty for 
locally-originated 
Stations; broadcast 
channel when received 
by antenna; 

for Satellite cable feeds: 
Sat Type, Satellite, 
Transponder, Channel 
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10 



15 



20 



30 



8. 



Affiliation 



Schedule Data Source 0 



20 



12 



10. 
11. 
12. 

END of 
RECORD 



Last Modified Date/ 10 
Time 

Effective Date/Time 10 
Expiration Date/Time 0 
Comments 0 
OA hex and/or 0D hex 



10 

10 
10 
300 



Network affiliation, if 
any. 

if left empty: schedule 
data is provided using 
the ID supplied in field 
1 

0 = > no data provided. 

for this station 

any other == ID of 

schedule data source 

yymmddhhmm 

yymmddhhmm 
yymmddhhmm 



Line Feed and/or Carriage Return 



LVIL 
Field # 
1. 



25 2. 



Table LVI 

A detailed description of the station list record format is provided in Table 
Name 

Station ID (12 numeric) 

Unique ID number assigned by vendor. This ID is used to identify 
the station or feed wherever this is required. 
Station Type (empty, or 1 byte, numeric) 
0=FuIl Power Broadcast 
1 =Low Pwr TV Station 
2=SatelliteFeed 
3 = Locally-originated 
4=other 
5= unknown 

Call Letters or Feed Name (up to 8 alphanumeric) 
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StarSigHt requires that no more than 8 characters be used to identify 
the Station or Feed. 

Usual Abbreviation of Name (1 to 4 alphanumeric) 
Note: 4 characters, maximum! If there is a well-known abbreviation, 
supply it here. Most cable subs don't think about East- and West- 
coast feeds, so HBO- WEST would generally be abbreviated as just 
HBO for cable subs. 
Explanation of Name (up to 120 bytes) 

Give the fully-expanded name, if different from above. For example, 

if Field 3 contains "YOUTH" and Field 4 contains "YTV", Field 5 

might contain "Youth Television". 

Native Channel (up to 13 bytes, alphanumeric) 

For broadcast and LPTV stations, this field would contain just a 

number. For satellite feeds, supply a comma-separated list that 

describes: Type of Satellite (C or Ku), which satellite (usually a letter 

and a number, like G5), which transponder (a number), and if 

necessary which channel within a transponder (required when, for 

example, 10 compressed channels are available on a transponder). 

This field should contain data if the "Station Type" field contains 0, 

1, or 2; it may be empty if "Station Type" is 3, 4, or 5. 

Super Stations such as WTBS, WGN and WWOR deserve special 

consideration. In their home markets, these stations are just normal 

broadcast stations with normal broadcast Native channel numbers; but 

when received from satellite, the Native channel number must refer to 

a satellite and transponder. This is to be handled by using two 

separate Station IDs to refer to the two distinct usages of these 

stations. If the schedule information is the same for both, this can be 

indicated by having one record give the other "Station ID" in the 

"Schedule Data Source" field. 

Affiliation (up to 20 characters) 

Which network(s), or IND, or empty if unknown 

Schedule Data Source (up to 12 numeric) 

if left empty: schedule data is provided using the ID given in field 1 
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0 = > rto data provided for this station 
any other == ID of schedule data source 
9. Last Modified Date/Time (10 numeric) 

The last time any field was modified. 
5 10. Effective Date/Time (10 numeric) 

GMT Date/Time this record became or will become effective. Used 
to specify Station information which is either current, or is not yet 
true, but will become true at a known future date and time, such as a 
change of name or Call Letters. This field specifies the date and time 
10 the information did or will become effective. . 

11. Expiration Date/Time (up to 10 numeric) 

GMT Date/Time this record did or will expire. Similar to the 
preceding field, this field specifies a future date and time when this 
piece of Station information (e.g., Call Letters) will cease to be in 
15 effect. 

12. Comments (up to 300 bytes) 

Whatever might be useful in assuring the channel or feed is 
unambiguously identified. 

Table LVII 

20 An example of a station list record is given in Table LVHI. 



25 



30 



Field # 


Field Name 


Sample Data 


1. 


Station ID 


140032965 


2. 


Station Type 


2 


3. 


Call Letters or Feed Name 


CARTOON 


4. 


Usual Abbreviation of Name 


TCN 


5. 


Explanation of Name 


The Cartoon Network 


6. 


Native Channel 


Ku,Gl,8 


7. 


Affiliation 




8. 


Schedule Data Source 




9. 


Last Modified Date/Time 


9309170930 


10. 


Effective Date/Time 


9309170930 


11. 


Expiration Date/Time 





10 
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12. Comments eh-Th-eh, eh-Th-eh, 

eh-Th-That's All, Folks! 
END of RECORD (END of RECORD) 

Table LW 

A record containing the data described above is as follows: 
1 40032965 1 2 1 CARTOON | TCN | The Cartoon 

Network|Ku,Gl,8| 1 1 9309170930 1 9309170930 1 |eh-Th^h,eh-Th^h, eh-Th-That's . 
All, Folks! | (END of RECORD) 
The Lineup List 

The Lineup database will contain one record for each currently-effective 
channel in each RG, and may also contain a ftiture lineup for each RG. A "channel- 
is any seperately-scheduled feed. Composite channels are described using a separate 
record for each part of the composite. 

Certain conventions must be observed, in order to minimize StarSight's 
15 processing burden: 

1- Each field is delimited from the next with an ASCII "pipe" (7C hex) 
character. Fields with a specified default size of 0 may be left empty 
if no data is available; fields with a nonzero minimum size are 
mandatory. 

20 2 - To inform StarSight that an RG is being deleted, a normal-looking 

RG record is transmitted, except that it contains a 0 in the "Lineup 
Record Count" field, as well as a specific Date/Time for expiration, 
in the "Expiration Date/Time" field; all other fields should be 
formatted as per this specification. This signals StarSight to stop 
doing the internal processing associated with this RG, as of the 
specified Date/Time. Note: due to the delay inherent in processing 
this type information, it is not a good idea to reuse this RG number to 
identify a new RG. To assure no problems of this nature, RG 
numbers should not be reused at all. 
30 3 - A ,ineu P must always be described in its entirety, with an RG record 

immediately followed by all the Lineup records associated with this 
RG. 



25 
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When there is both a current and a future lineup defined for an RG, 
the current information is transmitted first, with an RG record having 
the earlier of the two effective dates, followed by all die current 
lineup records; then another RG record having an effective date in the 
future followed by all the lineup records for the future lineup. 
If any Lineup data is provided for a given RG, the entire Lineup 
(including all currently-effective and all scheduled-to-become-effective 
data) for that RG must be provided. 

All the records which deal with a given RG must be contiguous in the 
file; e.g., it is not allowed to have records that deal with RG 100, 
then RG 101, then again with RG 100, in the same file. 
Lineup information is to be sorted in ascending order on the 
following key values: 

a. RG number 

b. Effective Date 

c. Source 

d. Tune Channel ft 

It is possible to explicitly schedule an "Expiration Date/Time" for the 
information in a given lineup, by providing this information in the 
optional field of this name in the RG record. 
Any change to any record of a Lineup must be reflected by updating 
the "Lineup Info Last Date/Time Modified" field in the RG record 
for that lineup. 

Note that there is not a field in the Lineup record for a "Last 
Date/Time Modified": this is handled by updating the "Lineup Info 
Last Date/Time Modified" field in the RG record; an update of the 
"Lineup Info Last Date/Time Modified" field implies that the entire 
Lineup for that RG has been updated and verified. 
Note that there is not a field in the Lineup record for "Effective 
Date/Time": this is handled by updating the "Effective Date/Time" 
field in the RG record; the value of the "Effective Date/Time" field 
implies that the entire list of Lineup records that follow this RG 
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record will become effective (or did become effective) on that Date 
and Time. 

RG record format is shown in Table LVIII. 



Field* 



15 5. 



Field Name 



Field Size Description 
MIN MAX 



1 



Record Type 
Lineup Record Count 1 



RG number 



RG group type 



RG name / 
Satellite Name 



8 



1 "R" = normal RG 

"S" =Satellite. 
4 Decimal # of Lineup 

records to follow. 
8 (The 8 digit I.D. 

number of this RG) 
1 0= broadcast 

l,2,3,4=cable 

5=satellite(TVRO) 
120 Unique name of this 

Reception Group 
(if cable, name 
of headend) 



6. 


Cable System name / 0 


120 


(if cable, name 




Satellite Abbreviation 






system) 


7. 


MSO name / Sat 


0 


120 


(if cable, name 




Operator 






MSO) 


8. 


Contact name(s) 


0 


120 




9. 


Contact tel number 


0 


20 




10. 


Street Address 


0 


120 




11. 


City 


0 


120 




12. 


State 


0 


2 




13. 


ZIP 


0 


10 




14. 


DMA Name /Sat 


0 


120 


(DMA) 




Orbit Pos 








15. 


DMA Rank 


0 


3 


(DMA Rank) 


16. 


ADI Name 


0 


120 




17. 


ADI Rank 


0 


3 
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18. 
19. 
20. 

21. 

22. 
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Communities Served 0 
Comments 0 
RG General Info 10 
Last Modified Date/Time 
RG Lineup Info 10 
Last Modified Date/Time 
Effective Date/Time 10 



Expiration Date/Time 0 



END of RECORD OA hex and/or 0D hex 
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300 
300 

10 yymmddhhmm 

10 yymmddhhmm 

10 GMT Date/Time this 
record became or will 
become effective. 
10 GMT Date/Time this 
record will or did 
expire. 
Line Feed and/or Carriage 
Return 



Table LVIII 

RG Field explanation 
Field# 

1. Record Type (1 byte) 

This field must always contain one of the uppercase ASCII characters "R" or 
"S", to specify that this record is an RG record. If Record Type is *S\ then 
the record is being used to describe a particular Satellite, and the meanings of 
certain fields are redefined (see details below). Both record types have the 
same number of fields, but several fields will always be empty when Record 
Type = "S\ 

2. Lineup Record Count (1-4 bytes) 

The decimal number of Lineup records that follow this record; that is: the 
number of following records used to completely define the Lineup of this 
RG. 

3. RG number (8 bytes) 

This number is the unique 8 decimal digit ID of this RG. RG numbers must 
not be re-assigned: once an RG number has been assigned, it may eventually 
pass out of usage (say, because a company goes out of business); but even in 
this case, its RG Number should not be reused. 



123 

RG group type (1 byte) 

The Lineup type defines what type of service this RG is targeted for: 

0= Broadcast TV, this is a conventional TV channel RG. 

1 = Standard cable system , this is a conventional cable frequency plan. 

2=IRC cable system (IRC is a modified cable frequency plan.) 

3=HRC cable system, (HRC is another modified cable frequency plan). 

4=Cable System, Frequency Plan Unknown 

5= Satellite 

RG Name (if Record Type="R") (up to 120 bytes) 

Satellite Name (if Record Type= "S M ) 

Use a verbose description of up to 120 characters to describe the RG or 
Satellite as unambiguously as possible. If a cable RG, use the MSO Name 
field if appropriate; RG Name should uniquely identify an entity that can 
have its own lineup. For example, each headend of a cable system can have 
its own lineup, so each headend should have a name which is somehow 
unique, even if it is only a unique number, or a unique combination of the 
Cable System Name with a number. 

Cable System Name (if Record Type = "R") (up to 120 bytes) 

Satellite Abbreviation (if Record Type = "S") 

If cable, this may be a system operated by a Multiple System Operator 

(MSO). If so, give the name commonly used in the community to identify 

this cable system. If satellite, give the usual letter/number combination used 

to refer to this satellite, such as G3 for Galaxy 3. 

MSO Name (if Record Type = "R") (up to 120 bytes) 

Satellite Operator (if Record Type = "S") 

If cable, this may be a system operated by a Multiple System Operator 

(MSO). If so, name the MSO. If satellite, name the operator of the satellite. 

RG local contact (0 to 120 bytes) 

Name of a local contact person at the cable company. 

Contact Telephone Number (up to 20 bytes) 

Number of a local contact person at the cable company. 

Street Address (up to 120 bytes) 

Street address of a local contact person at the cable company. 
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11. City (up to 120 bytes) 

Name of the city where contact is located. 

12. State (0 to 2 bytes, alpha) 

This is the US Postal Service's 2-character abbreviation for the state. 
5 13. ZIP (Oto 10 bytes) 

The ZIP code is formatted as 5-bytes, dash, 4-bytes. Quite often only the 
first 5 bytes are available. 

14. DMA Name (if Record Type = "R") (up to 120 bytes) 
Orbit Position (if Record Type = "S") 

10 What name does Nielsen use to refer to the DMA within which this RG lies? 

15. DMA Rank (always empty when Record Type = "S w ) (3 bytes, numeric) 
What is the Nielsen DMA Rank for the DMA within which this RG lies? 

16. ADI Name (always empty when Record Type = "S") 
(up to 120 bytes) 

15 What name does Arbitron use to refer to the ADI within which this RG lies? 

17. ADI Rank (always empty when Record Type = "S") 
(3 bytes, numeric) 

What is the Arbitron ADI Rank for the ADI within which this RG lies? 

18. Communities Served (empty when Record Type = "S") 
20 (up to 300 bytes) 

Comma-separated list of towns, cities, communities, neighborhoods, districts 
or boroughs served by this RG. The list should be as succinct and correct as 
possible, but should err, if at all, on the side of including too many, rather 
than too few, names. 

25 19. Comments (up to 300 bytes) 

Any special information that might help to distinguish this RG from others 
nearby, or anything else the person doing data entry feels is important for 
StarSight to be aware of, especially as it relates to trying to identify which 
RG a new subscriber is in. 

30 20. RG General Info Last Modified Date/Time (10 bytes, numeric) 
GMT Date and Time this record was last modified: format 
yymmddhhmm;For example: 9307110514. 
21 . RG Lineup Info Last Modified Date/Time (10 bytes, numeric) 



10 



15 
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GMT Date and Time any Lineup information associated with this RG was 
last modified: format yymmddhhmm;For example: 9307110514. Note: the 
value "0000000000" is reserved, and has the special meaning: "No Lineup 
available for this RG". 

22. Effective Date/Time (10 numeric) 

GMT Date/Time the following lineup became or will become effective. Used 
to specify lineup information which is either current, or is not yet effective, . 
but will become effective at a known future date and time. This field 
specifies the date and time the information did or will become effective. 

23. Expiration Date/Time (empty, or 10 numeric) 
GMT Date/Time this record did or will expire. Similar to the preceding 
field, this field specifies a future date and time when this piece of lineup 
information will cease to be in effect. The Date/Tune specified is assumed to 
be non-inclusive of the final minute, meaning that the lineup expires at the 
beginning of this minute, not the end. 

An example of an RG record is provided in Table LK: 



20 



25 



30 



Field* 


Field Name 


Sample Data 


1. 


Record Type 


R 


2. 


Lineup Record Count 


20 


3. 


RG number 


12345 


4. 


RG group type 


1 


5. 


RG name 


12345 


6. 


Cable System name 


Megacable of Fremont. 


7. 


MSO name 


Megacable Conglomerates, Inc. 


8. 


Contact name(s) 


Bob Engineer 


9. 


Contact tel number 


(510) 555-1212 


10. 


Street Address 


2020 Main Street 


11. 


City 


Fremont 


12. 


State 


CA 


13. 


ZIP 


94538 


14. 


DMA Name 


San Francisco Bay Area 


15. 


DMA Rank 


5 



10 
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16. 
17. 
18. 
19. 

20. 

21. 

22. 
23. 
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ADI Name 
ADI Rank 
Communities Served 
Comments 

RG General Info 

Last Modified Date/Time 

RG Lineup 

Last Modified Date/Time 
Effective Date/Time 
Expiration Date/Time 
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San Francisco Bay Area 
5 

Fremont, Union City, Sunol 

Sunol is closer to Dublin, but is on this 

cable system. 

9307060841 

9307060841 

9307060841 • 



END of RECORD \x0Ahex 

Table LDC 

A sample record containing the data specified above is as follows: 

R 1 20 1 12345 1 1 1 12345 1 Megacable of Fremont. | Megacable Conglomerates, 
Inc. | Bob Engineer | (510) 555-1212 1 2020 Main 

Street | Fremont | CA 1 94538 1 San Francisco Bay Area 1 5 1 San Francisco Bay 
Area|5|Fremont, Union City, Sunol j Sunol is closer to Dublin, but is on this 
cable system. 1 9307060841 (9307060841 (9307060841 ( (ENDOF RECORD 

The lineup record format is shown below in Table LX. 



Field ft 



2. 

3. 
4. 



Field Name 

Record Type 

RG number 

Tuneable channel 
Source 



Field Size Description 
MIN MAX 



1 



1 
0 



1 "L" for normal lineups; "T" for 
Satellite TVRO lineups 

8 (The 8 digit I.D. number of this 
RG file) 

3 (channel # or letter) 

1 If multiple signal sources are 
used, which is selected for this 
channel? If there is only 1 
signal source, this field should 
be left empty. 
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5. Channel ID # 12 12 Must be a valid Station ID 

number from the Station List 
file 

6. Channel Type 1 1 0= not identified 

1= Basic, 

2= Extended Basic, 

3= Premium, • 

4= PPV 

7- Days 0 7 These numbers are single bytes 

with the-following meaning: 

1 = Sunday 

2 = Monday 

3 = Tuesday 

4 = Wednesday 

5 = Thursday 

6 = Friday 

7 = Saturday 

For non-composite channels, 
this field should be left empty. 

8. Start Time 4 4 GMT Hour/Minute 

9. Stop Time 4 4 GMT Hour/Minute 
12. End of Record OA Hex and/ ASCII Linefeed and/or 

or 0D Hex Carriage Return Character 
Table LX 

A detailed description of the lineup record is as follows: 

1 . Record Type (1 byte) 

"R w = normal Lineup Record; m T = Satellite TVRO Lineup Record. 

2. RG Number (8 numeric) 

This is the same number used to identify the Reception Group in the RG 
record. 

3. Tunable channel (1 to 3 bytes) 

This is the channel you would tune to in order to receive this programming. 
It is the cable channel number or letter for the cable system (when Record 
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Type= w L B ), or the transponder number for TVRO (Record Type= "T"). If 
two or more records have the same tune channel then this is a composite 
channel. 

4. Source (empty if Record Type = "T") 

5 Some cable systems have the capability to select among two or more separate 

cables; specify which cable (A, B, ..) to use, if this is such a system. Leave 
empty if this is a single-source system. 

5. Channel ID (12 bytes) 

This is the unique number used to identify the schedule information for this 
10 channel. It refers to one of the stations defined in the -Station List, using its 

unique Station ID. 

6. Channel Type (1 numeric) 

What kind of channel is this (applies to cable and TVRO lineups): 

a. = Don't know 
15 1 = Basic 

2 = Extended Basic 

3 = Premium 

4 = PPV 

b. can be assigned meanings at vendor's request 
20 7. Days (0 to 7 bytes) 

These are the days in which data from this feed is used. For non composite 

channels the days would be 1234567. For the non-composite case, since this 

is by far the most common case, leaving the field empty shall be defined to 

be equivalent to specifying all 7 days. Any combination of up to 7 days can 
25 be specified in this field. 

These numbers are single bytes with the following meaning: 

1= Sunday 2 = Monday 

3= Tuesday 4 = Wednesday 

5= Thursday 6 = Friday 
30 7= Saturday 

Thus a "Days" field of 257 specifies the days Monday, Thursday and 

Saturday. 
8. Start Time (4 bytes) 
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This is the starting time (GMT) at which data from this channel should be 
used. For a non-composite channel the start time will always be 0000 hours 



5 



9. 



GMT. 

Stop Time (4 bytes) 

This is the stop time (GMT) for data from this station. For a non-composite 
channel the stop time will always be 0000 hours GMT. The Date/Time 



specified is assumed to be non-inclusive of the final minute, meaning that the 
lineup expires at the beginning of this minute, not the end. 
10. End of Record 



Example: Lineup involving Current and Future data for a two-cable system: 

The fictitious lineup below illustrates a system that uses only two channels on 
each of two cables, for which there exist both a current and a future lineup. The data 
are sorted as described above; that is the currently-effective information for source A 
15 is given first (sorted in ascending order by tuned channel number), followed by the 
currently-effective information for source B, then the future information for source 
A, and finally the future information for source B. The record in boldface is the only 
record that is actually different between the two lineups; channel 2 on Cable B is 
being reassigned. Note, however, that the future lineup is given in its entirety. 



20 R 1 4 1 00000010 1 4 1 TUCSON CABLEVISION | TUCSON 

CABLEVISION | INTERMEDIA PARTNERS | CATHY | (602)629-8470 1 1440 E 
15TH 

ST|TUCSON|AZ|85719-6495| 1 1 1 1 931 0000000 1 931 0000000 1 9308010400 1 9401 150 
400j 

25 L|00000010|2|A|10039521|l|1234567iO|0|| 

L 1 000000 1 0 1 3 1 A 1 1 0042895 1 1 1 1 234567 1 0 1 0 1 

L 1 00000010 1 2 1 B 1 503409 1 1 1 1234567 1 0 1 0 1 

L 1 00000010 1 3 ( B 1 9353489 j 1 1 1234567 1 0 1 0 1 

R 1 4 1 00000010 1 4 1 TUCSON CABLEVISION | TUCSON 
30 CABLEVISION | INTERMEDIA PARTNERS | CATHY | (602)629-8470 1 1440E 

15TH ST | TUCSON | AZ 1 85719-6495 1 1 1 1 1 93 10000000 1 931 0000000 1 940 11 50400 1 1 

L 1 00000010 1 2 1 A 1 10039521 1 1 1 1234567 1 0 j 0 1 

L 1 000000 1 0 j 3 1 A 1 1 0042 895 1 1 1 1 234567 1 0 1 0 1 



10 



ASCII Linefeed (OA Hex) and or Carriage Return (0D hex). 



WO 95/31069 



PCTAJS95/05169 



130 



L 1 00000010 1 2 1 B 1 04509845 1 1 1 1234567 j 0 1 0 1 

L 1 00000010 1 3 1 B 1 9353489 1 1 1 1234567 1 0 1 0 1 

Example: Deleting an RG 

The example below illustrates how to delete the RG which was described in 
5 the preceding example, effective January 15, 1994 at 0400 GMT: 

R 1 0 1 00000010 1 4 1 TUCSON CABLEVISION | TUCSON 

CABLEVISION | INTERMEDIA PARTNERS | CATHY | (602)629-8470 1 1440 E 

15TH ST|TUCSON|AZ|85719-6495 

1 1 1 1 19310000000|9310000000|9401150400|940115 
0 Note that this is just a normal-looking RG record, with the Expiration Date/Time 

filled in. Unlike the usual case, there are no following Lineup Records, as indicated 

by the 0 in the "Lineup Record Count" field. 

Glossary Of Terms 

5 The following terms are commonly used in the following description. Other 

terms not listed in this glossary should be familiar to personnel in the listings' data 
industry and to personnel involved in similarly connected businesses. 
CAC Community Access Channel 

Channel Discrete frequency band allocated to a TV station 

0 Composite Channel Two or more PO's time sharing the programming on a single 

channel. 

DP Data Provider, (provider of program listings' data) 

Data Provider Supplier of TV program listings' data. 

FIELD A sub part of a record, (records are made up of multiple 



fields) 



GMT 



StarSight 



HRC 



Greenwich Mean Time (Universal Mean Time). 
Cable system frequency transmission standard. 
StarSight Telecast Incorporated 



IRC 



Local 



Cable system frequency transmission standard. 

The broadcast TV station that resides within 35 miles of the 



MAP 



cable provider. 

Reference to the physical area of a reception group (RG) 
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MPAA 



10 



15 



20 



25 



30 



Motion Picture Artists Association (suitability guidelines for 
viewers). 

Multiple System Operator (operates more than one cable 
system) 

Program Originator (TV station,TV cable provider,Satellite 
video provider). 

A segment of evening time considered as Prime Viewing 
Time, 
(see PO) 

Pacific Standard Time (West Coast Time), r- 
A defined string of ASCII characters within a file. 
Reception Group, The available TV channels in a well-defined 
geographical area. 

The length in minutes of a show or movie. 
The cable system ^head end, or Broadcast TV station that 
carries the StarSight program data. 
A file containing records in Pipe Delimited Format which 
contain schedule listing information as described herein. 
The local time that the show begins.(hour - minute) 
Abbreviation for Subscriber Unit. Used to decode StarSight 
data. 

Syndicate Exclusivity 

Transmission Control Protocol / Internet Protocol 

-r 

A predetermined distance or area from a broadcast station. 
Overview of this description 

The following description defines in detail the requirements of a Data 
Provider in relation to delivering television listings' data to StarSight Telecast. It 
defines in detail the format of the Show list (pipe-delimited file). The format of each 
record within these files are also defined. 

Also outlined are the details of the electronic delivery of these files to 
StarSight, and the requirements and details of special files that are required due to 
nation wide program oddities, such as SyndEx. 



MSO 
PO 

Prime Time 

Program Originator 

PST 

Record 

RG 

Runtime 
Service Provider 

Show list 

Start Time 
SU 

SyndEx 
TCP/IP 
Specified Zone 
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The formats of the Show list records that are used in building the StarSight 
electronic database are highly integrated into our database program and these formats 
must not be altered or changed in any way without the written consent of StarSight 
Telecast. Use of the Vendor-Defined Fields (see below) is allowed, provided the 
5 syntax and meanings of the fields used are documented in advance. 
File Transfer Specifications. 
File Transfer Media and Speed. 

The Show list files will be transferred electronically to StarSight Telecast's 
UNIX file system through a router connected to the DP's Ethernet and a digital 
10 leased line, using the standard TCP/IP program, FTP. The operating speed of the 
leased line will be sufficient to transfer all data files in a reasonable length of time. 
File Transfer Protocol and Compression. 

The data will be transferred into StarSight Telecast's UNIX file system using 
TCP/IP file transfer protocol or other file transfer protocol standard mutually agreed 
15 upon. The files may require compression due to the bulk of data being transferred 

using a mutually agreed upon data compression algorithm compatible with our UNIX 

file system. 

File Transfer details 

The files will be transferred to StarSight on a daily basis 7 days a week with 
10 the file transfer completed by 0800 hours PST. The daily file transfer will be into the 
home directory corresponding to the login name used to perform the file transfer. 

The "Main" file download to StarSight will always be for the date 12 days 
into the future. Thus if today is the 10th, today's data downlbad would be for start 
times beginning at 0000 hours GMT on the 22nd. 
15 (see GMT specification below in this description) 

Since the data files are sent on a daily basis some mechanism must be in 
place to allow for the updating of a program listing that has already been transferred. 
This is accomplished via the "Update" file. An Update file contains records of all 
changes that have been made since the last Update file was produced, which modify 
0 any of the data for any date which is still "active". An "active" date is defined as the 
dates beginning with today's date, and spanning the 11 days following (that is, all 
dates from today to the date covered by today's "Main" file, but not including that 
date. 
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A class of service to be implemented will require "Flash Updates"; this class 
of service would provide a "Flash Update" file within 5 minutes after entry of any 
change. Such files would "trickle" across the leased line to StarSight throughout the 
* day. 

5 Show list file Introduction. 

StarSight Telecast operates a data network that delivers specially formatted 
data to StarSight subscribers located throughout the USA. This data is used to build 
an "on screen program guide" called StarSight that enables its subscribers to 
interactively view television program listings on their TV screen. The information 

10 for this network is derived from the StarSight database that is built by a computer 
program running on our UNIX computer. To build this database a data provider is 
required to supply StarSight with program' listing files called Show list files. 
GMT. 

A Show list file is a set of chronologically ordered records of television 

15 program listings. StarSight needs Show list files with the first record having its start 
time at 0000 hours GMT or for the first show starting after 0000 hours GMT. Thus 
the first record in each Show list file will be for the first show at or after Midnight 
GMT and the last record in a Show list file would be for the last show starting 
before 2400 hours GMT. 

20 In other words a given Main file Will contain only records for all POs for one 

day with one day starting at 0000 GMT and ending at 2400 GMT. Conversely a 
Main file must contain all of the shows for all POs for that day. 
Daylight saving time. 

Since the "Start Time" field of any Show list record is always given in terms 

25 of GMT, the data provider is cautioned that daylight saving time must be accounted 
for twice a year, once in the spring when daylight saving is invoked and once in the 
fall when returning to standard time. This time modification must take place for all 
program data and all PO's unless the PO resides in a non daylight saving time state 
or county. Daylight saving time will cause the DP to compile or transfer records into 

30 the PO file that are corrected for the 1 hour forward adjustment in spring and the 1 
hour backward adjustment in fall. 
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Please note that once showtimes have been adjusted to GMT, the Show list 
records should always be contiguous with no gaps or overlaps even on Daylight 
Saving transition dates. 
SyndEx and Network Exclusivity 
5 Due to FCC regulations a TV cable provider is required to block out 

programming (at the request of the local station) that directly conflicts in both time 
and content with the programming of a local broadcast TV station. This may cause 
the cable provider to substitute programming on that channel for the time in conflict. 
StarSight must be informed of a SyndEx blockout no later than 24 hours prior to the 
10 blockout, in order to display the correct schedule for the blocked-out time slot. 
Sports Blackout 

Due to FCC regulations a sporting event can be blacked out from local TV 
coverage if a given percentage of tickets are not sold within 24 hours of that event. 
StarSight requires knowledge of the blackout. 

15 Composite Channels 

Some cable providers will divide a cable channel into multiple programming 
segments inserting programming from two or more program originators on one 
channel, at different times. The DP is required to provide StarSight with information 
that explains clearly what service is on such a channel at any given time. This 

20 information will be provided in the PO list for the channel in which the composite 
programming occurs. 

The multiple PO information for composite channels is handled in the "RG 
List Format Specification" explained above. 
Community Access Channels 

25 The FCC requires each cable provider to support at least one Community 

Access Channel (CAC) for public use. Private citizens can request program time on 
this channel for their public views, public information or approved public 
programming. 

StarSight requires a Show list file with the program information for each CAC, with 
30 the CAC Show list file name bound to the cable system name. 
Low Power Stations LPTV 

Low power (mostly privately owned) broadcast TV Stations exist in many 
areas of the United States. Some of these low power stations will require program 
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listing support by the DP. These will be handled on a station by station basis with a 
Show list file for each LPTV. 

The precise format in which the data for SyndEx, Network Exclusivity, 
Sports Blackout, Composite Channel, Community Access Channel and Low Power 
5 Stations is to be provided, is to be determined. 
Show list' File Definition 

Show list files are made up of multiple records containing television program . 
listings. The Show list records have a fixed number of fields. Most fields are of a 
fixed size with a few fields of variable size. This gives a Show list record a 
10 minimum and a maximum byte size. (See the Show list record.field definition for the 
exact MIN/MAX size.) 

Except for the end of record terminator, OA hex (line feed) The Show list 
files will contain only ASCII characters and only within the range of 20 hex to 7E 
hex inclusive. This precludes any control codes, new line codes or end of record 
15 codes being part of any Show list file. 
Show list File Names. 

There are three sorts of files discussed in this description. They all have the 
same record format, but they are used somewhat differently. They are referred to as 
the "Main" file, the "Update" file, and the "Flash" files for a given date. The Main 
20 file contains only the data for one particular date. It amounts to the initial load of all 
data for that date. The Update file contains information that revises Show list data 
that was provided on earlier days. It contains data which may encompass several 
different days, just depending on what new information has been entered. The Flash 
file contains update information that has just been entered. 
25 The Main filename shall consist of the letters "MAIN" followed by four 

digits that represent the date, then [optionally] ,a period and the suffix "DAT". For 
example "MAIN0812.DAT" is a valid Main filename, and so is "MAIN0812". 

The Update filename shall consist of the letters "UPDT" followed by four 
digits that represent the date, then [optionally] ,a period and the suffix "DAT". For 
30 example, UPDT0812.DAT is a valid Update filename, as is "UPDT0812". 

Flash filenames shall consist of the letters "FLSH" followed by four digits 
that represent the time of day, then [optionally] ,a period and the suffix "DAT". For 
example, FLSH0642.DAT is a valid Update filename, as is "FLSH0642". 
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Since interfaces to different types of computer systems are a given, the file naming 
convention has been chosen so as to work with virtually any computer operating 
system in existence. The alpha letters within filenames may be in either all uppercase 
or all lowercase; mixed case is not allowed. 
5 Each PO's data will have its own portion of the file, identified by identifying 

the PO in the first field of each record concerned with that PO. The identification 
number (not to exceed 12 bytes) will consist of ASCII digits 0 through 9 only, and . 
will be identical to the Station ID number assigned for this PO in the Station List 
file, which is defined in a separate document. 
10 Show list File Length. 

Each file will contain Show list records as defined elsewhere in this 
document. The file will contain as many of these records as required to fill one 24 - 
hour day. 

Each record in a given file has a program length as defined in the "runtime" 
15 field and a "starttime B as defined in the starttime field of the Show list record. These 
Start Times and runtimes will cause the content of a file to be contiguous for the 24 
hour day, leaving no gaps in the time sequence. 
Contiguous Files. 

AH "Main" file records will have contiguous Start Times and run length from 
20 day to day and week to week, etc., without any time gaps. 

The Show list record format is shown in Table LXI. 
Field No. FIELD NAME MAX MIN DESCRIPTION 

(bytes) 

25 1 • Station ID number 12 (1) Unique ID number for this PO 

2. Start Date 8 (8) YYYYMMDD 

3 - Start Time 4 (4) Program start time: 

hour, minutes 

4 - Runtime 4 (4) Program runtime minutes 
30 0005 to 9999 

5 - Close Caption 1 (1) Close caption indicator. Y, N 

6- Stereo 1 (l) Program audio broadcast type. 

Y,N 
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7 


color 


i 


(i) 


Program video broadcast type. 
C,B 




Q 
O. 


Type 


3 


(3) 


Program Type (see table 1, 
table 2) 


< 


Q 

y . 


movie iNuniDer 


1 A 
1U 


✓A\ 

(0) 


Up to ten decimal digits 




10 
lv. 


oroup id 


J 


(5) 


unique series program link, 0 to 
65536 




1 1 


X llic 




(0) 


Program title. 






jrrogram uescr. # i 


1AA 


/A\ 

(0) 


Program description. 


10 




rTograiii uescr. #z 


oaa 
ZUU 


/A\ 

w 


Progranvdescription. 




14 

1*T. 


rrogram uescr. #3 


1UU 


/A\ 

(0) 


Program description. 




1<k 

13. 


rrogram Descr. #4 


50 


(0) 


Program description. 




ID. 


Critique 


l 


(1) 


Movie critics rating 0, 1 ,2,3 ,4 




17 


Episode 


50 


(0) 


Program episode description. 


ID 


1 8 
15. 


Year 


4 or 


(0) 


Year the movie was produced. 




1Q 


Director 


25 


(0) 


Name of the movie director 




on 


Last Name of Star 1 


25 


(0) 


Last name of star in the movie. 




71 
Zl . 


First Name of Star 1 


25 


(0) 


First name of star in the movie. 




77 
ZZ. 


Last Name of Star 2 


25 


(0) 


Last name of star in the movie. 


90 

ZU 


71 
Zj. 


First Name of Star 2 


25 


(0) 


First name of star in the movie. 




Z*f. 


Last Name of Star 3 


25 


(0) 


Last name of star in the movie. 




7^ 
ZD. 


First Name of Star 3 


P 


(0) 


First name of star in the movie. 




7£ 
ZD. 


Action 


l 


(1) 


T, F. 




07 
Z/. 


Adventure 


i 


(1) 


T, F. 


0< 


OO 
ZO. 


Biography, Biographical 1 


d)T, F. 




70 

Z7. 


Classic, Classical 


l 


0) 


T, F. 






Comedy 


I 


(1) 


T, F. 




31 


Dance 


i 


0) 


T, F. 




JZ. 


Docudrama 


l 


(1) 


T, F. 


30 


33. 


Documentary 


l 


(1) 


T, F. 




34. 


Drama, Dramatic 


l 


(1) 


T, F. 




35. 


Fantasy 


l 


(1) 


T, F. 




36. 


Historical 


l 


(1) 


T, F. 
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37. 


Horror 1 


0) 


T, F. 




39. 


Martial Arts 1 


(1) 


T, F. 




40. 


Musical 1 


(1) 


T, F. 




41. 


Mystery 1 


(1) 


T, F. 


5 


42. 


Opera 1 


(1) 


T, F. 




A O 

43. 


Romance, Romantic 


0) 


T, F. 




44. 


Satire, Satirical 1 


0) 


T, F. 




45. 


Science 1 


(1) 


T, F. 




A f 

46. 


Science Fiction 1 


(1) 


T, F. 


10 


47. 


Suspense 1 


(1) 


T, F. . 




48. 


Thriller 1 


0) 


T, F. 




49. 


Western 1 


0) 


T, F. 




50. 


Situation Comedy 1 


(1) 


T, F. 




51. 


G 1 


0) 


T, F. 


15 


52. 


NC17 1 


(1) 


T, F. 




53. 


NR 1 


(1) 


T, F. 




54. 


PG 1 




T, F. 




55. 


PG 13 1 


(1) 


T, F. 




56. 


R 1 


(!) 


T, F. 


20 


57. 


AO 1 


(1) 


T, F. 




58. 


PROFANITY 1 


(1) 


T, F. 




59. 


NUDITY 1 


(1) 


T, F. 




60. 


VIOLENCE 1 


<*> 


T, F. 




61. 


ADULT SITUATION 


1 


0) T, F. 


25 


62. 


ADULT THEME 1 


(1) 


T, F. 




63. 


ADULT LANGUAGE 


1 


(1) T, F. 




64. 


PPV EVENT 1 


(1) 


T, F. 




64. 


1st 

Vendor-Defined Field 






30 


65. 

63+n. 


2nd 

Vendor-Defined Field 
nth — 







Vendor-defined Field 
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END OF RECORD 1 (i) LINEFEED 

('\xOA hex') 

Table LXT 

END OF RECORD markers and end of file markers will be a single 
LINEFEED (OA hex) and or CARRIAGE RETURN (0D hex) 

Show types for general programming are shown in Table LXII: 



Show Type Code 


Description ' 


CHL 


Children's Shows 


COM 


Comedies 


DOC 


Documentaries 


MAG 


Magazine 


MIN 


Mini-Series 


MOV 


Movies 


REL 


Religious 


GAM 


Game 


SGN 


Sign Off 


MUS 


Musicals 


SER 


Series 


SPC 


Specials 


SRL 


Soaps & Serials 


TLK 


Talk 


INErW 


News 


EXR 


Exercise 


MIS 


Miscellaneous 


NAT 


Nature 


HOW 


How-to 


MED 


Medical 


NET 


Network Series 


SYN 


Syndicated Series 


BUS 


Business 


PUB 


Public Affairs 


LAP 


Local Access Programming 


PDP 


Paid Programming 
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EDU Education 
UNK Unknown 

Table LXII 

NOTE: 

Show type designators are always of fixed 3 character length. More designators may 
be added as required. 

Show types for sports programming are shown in Table LXIII: 



10 



15 



20 



25 



30 



SHOW 

TYPE 

CODE 

LSB 

LSK 

LSW 

LSX 

LBC 

LSN 

LSF 

LSG 

LSY 

LSH 

LSE 

LSL 

LSA 

LSS 

LSQ 

LST 

LSJ 

LSP 

LS@ 

LSZ 

LSO 

SP1 



DESCRIPTION 

TYPE 
CODE 



SHOW 



DESCRIPTION 



Baseball - Live 

Basketball -Live SPK 

Bowling - Live SPW 

Boxing - Live SPX 

Bicycling - Live SBC 

Fishing - Live SPN 

Football - Live SPF 

Golf - Live SPG 

Gymnastics - Live SPY 

Hockey - Live SPH 

Horse Events - Live SPE 



Lacrosse - Live 



SPL 



Motor Sports - Live SPA 

Soccer - Live SPS 

Snow Skiing - Live SPQ 

Tennis - Live SPT 

Track/Field - Live SPJ 

Sports Live SPO 

Water Sports - Live SP@ 

Wrestling - Live SPZ 

Volley Ball - Live SSO 
Sporting Shows 



SPB Baseball 
Basketball 
Bowling 
Boxing 
Bicycling 
Fishing 
Football 
Golf 

Gymnastics 

Hockey 

Horse Events 

Lacrosse 

Motor Sports 

Soccer 

Snow Skiing 

Tennis 

Track/Field 

Sports 

Water Sports 
Wrestling 
Volley Ball 
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Table LXIII 

NOTE: 

Show type designators are always of fixed 3 character length. More 
designators may be added as required. ) 
5 Detailed Show list field class explanation. 

The Show list record fields are divided into four classes. They are data fields 
that contain the program information, the delimiter fields that separate the data 
fields, the record terminators that terminate and separate the records and the end of 
file terminator. 

i- 

10 Explanation of the field classes. 

Note that all of the fields in the following specification have a minimum and 
a maximum size described as bytes. Most fields are of a fixed length and must not 
vary from that specified length. Other fields have a variable minimum and a 
maximum length while a few are defined as a minimum or maximum. Even if a 

15 fixed length field contains no meaningful data, it must be padded out to its minimum 
length with the appropriate character. The maximum field length must also be 
adhered to and no field is ever allowed to exceed its maximum length. 
Data Field Text 

The text contained in any field will contain no control codes and all fields 
20 will contain only the ASCII character set within the range of the hexadecimal values 

Sfc---.- 

20 to 7E inclusive. 
Delimiter 

This one byte character is the pipe • j ' ( PIPE ASCII 7C hex ). It separates 
the different fields of a Show list record, it is unique within a Show list record and 
25 will not be used anywhere else in the Show list record except as a delimiter. There 
are equal numbers of delimiters and data fields. The Show list records have the 
pattern of FIELD, DELIMITER , ., . , FIELD, DELIMITER, END OF RECORD. 
A delimiter follows the last data field of any record. 
End Of Record 

30 A 11 records are terminated with an end of record terminator that follows the 

last delimiter of the last data field in a Show list record. This terminator is the ASCII 
code for Line Feed (OA hex), or Carriage Return (0D hex), or both together in either 
order. 



10 



WO 95/31069 PCTAJS95/05169 

142 

End Of File 

The end of file terminator is defined to be the text string "ZZZZZEOF". The 
final data record of a Show list file must be followed by an End of File terminator, 
to signal that all data has been transmitted. 
Detailed Data Field Explanation. 
Field it 

1. Station© 

(1 to 12 bytes) The Station ID is the unique number (assigned by the data 
provider: see the Station List record format) used to refer to this program originator 
(TV station, cable channel or satellite provider). It is never greater than 10 decimal 
digits. No other characters are allowed. 

2. Start Date 

(8 bytes) 8 byte number describing the GMT date when the jprogram 
will air. (year, month, day) This date must be the same for all records in a given 
15 file. Bytes 1 through 4 define the current year, for example: 1991. 

Bytes 3 and 4 define the month, with January numbered as 01 , December as 

Bytes 5 and 6 display the day of the month from 01 to 31. 

3. Start Time 

20 ( 4 b y tes ) 4 b y te number is the program air time GMT and is entered as 

military time. 

Bytes 1 and 2 are the hour in GMT time that the program will air. 
(Example 

6am = 06, 4 
25 noon = 12, 
6pm = 18, 
midnight = 00) 

' Bytes 3 and 4 are the minute that the program will air. 
(Example one MIN past the hour =01, 1 minute before the hour =59) 
30 4. Runtime 

(4 bytes) Program length in minutes. The minimum show run time length is 
0005 minutes and the maximum length is 9999 minutes. (The StarSight data base 
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program breaks shows with runtimes greater than 240 minutes into multiple shows of 
240 minute lengths.) Runtime data is shown in Table LXIII. 
Field Name Field# Sample Data 

Station ID 1 5963215^ 

5 Start Date 2 991231 

Start Time 3 0900 

RunTime 4 0060 

Table LXIII 

Sample Fragment of the above Show list record fields. 
10 5963215 S 1 1 991231 1 0900 1 | 

Field # 

5. Closed Caption 

(1 byte) If the show is closed captioned this field will be a "Y" (yes). If not it 
15 will be "N" (no) [ 

6. Stereo 

(1 byte) If the show is in stereo this field will be a "Y" (yes). If not it will be 
■N" (no). 

7. Color 

20 (1 byte) If the show is in color this field will be a "C" (color). If not it will 

be "B" (black & white). 

8. Type 

(3 bytes) mnemonic, indicating the program type indicating movie, sports, 
news, talk show, etc. 
25 (See Tables LXI and LXII) 

9. Movie Number 

(0 to 10 decimal digits) This unique number is provided by the data provider 
as a unique number for a show and is different for the title of every show or movie 
ever made. Once used this number remains locked for future reference to that title. 
30 Examples of these fields are given in Table LXTV. 

Field Name Field* Sample Data 

Closed Caption 5 Y 
Stereo 6 N 



WO 95/31069 PCT/US95/05169 

144 

Color 7 C 

Type 8 MOV 

Movie Number 9 1234567890 

Table LXIV 

5 A sample fragment of the above Show list record fields is as follows: 
Y|N|C|MOV|1234567890| 

Field ff 

10. Group ID 

(5 bytes) This 5 byte number will be from 00000 for no program link, to 
10 65535 for up to 65,535 unique program links. This number allows for unique 
groupings of two or more special programs or shows that may need to be linked 
together for recording purposes. The linking or grouping of these programs would be 
required for the series recording of programs that do not have the same title name as " 
in ROOTS 1 and ROOTS 2. This field will be 00000 if there is no program link and 
15 a unique decimal number up to 65,535 if there is a link. This unique number is kept 
until the linked programming is completed and any show with a reference to that 
number has passed out of the database. After that time, this number can be recycled 
and used over again. No provision is made to lock a Group ID number to any show 
on a permanent basis. 

20 The upper bound of 65,535 is necessary since this number is converted to a 2 

byte binary number by StarSight and sent to the SU in this manner. 

This number may be used to cross channel boundaries and link together as a 
group two or more shows on two or more different channels, provided that there is 
no conflict in record times. 
25 11. Title 

(0 to 50 bytes) This field contains the title or name of the program, names of 
sports team, talk show, etc. 

Examples of these fields are given in Table LXV. 
Field Name Field# Sample Data 

30 Group ID 10 0000 

Title 11 Manflys. 

Table LXV 

A sample fragment of the above Show list record fields is as follows: 
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0000 1 Man Fly sj 



The following four program description fields are to have different 
descriptions when available. Multiple descriptions will not show as multiple copies of 
the same description. A description must go into the smallest field that it will fit 
completely into. If 4 different program descriptions exist, insert the descriptions into 
the appropriate length field in descending order. 

Fields 12 - 19: Descriptions, Critique, Episode Title, Production Year, and Director. . 

12. Program Description 1 (0 to 300 bytes) This is a longest description of 
the of the program, show, sporting event, etc. 

13;Program Description 2 (0 to 20O bytes) This is a shortened description of 
the of the program, show, sporting event, etc. 

14:Program Description 3(0 to 100 bytes) This is a shortened description of 
the of the program, show, sporting event, etc. 

15. Program Description 4 (0 to 50 bytes) This is the shortest available 
description of the of the program, show, sporting event, etc. 

16. Critique (1 byte) Critics rating of the movie. This is '0' if there is no 
rating or a 1,2,3 or 4 depending upon the quality of the movie, 4 being the best. 

17. Episode (0 to 50 bytes) This provides for the episode description of a 
series show. 

18. Year (0 or 4 bytes) This is the year that the movie or show was 
produced. (1956, etc.) 

19. Director (0 to 25 bytes) The name of the movie director. 
Examples of these fields are given in Table LXVI. 

Field Name Field* Sample Data 

Description 1 12 Man sprouts wings, flys south for the winter and saves 



Description 2 



13 



the population of a foreign country 

Man sprouts wings, flys south for the winter and saves 



Description 3 
Description 4 
Critique 
Episode 



15 



14 



a country 

Man sprouts wings and saves a country 
Man flys and saves country 



16 



4 



17 



Flying man 



Year 



18 



1999 



10 
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Director 19 John Filmmaker 

A sample fragment of the above Show list record fields is as follows: 
Man sprouts wings, flys south for the winter and saves the population of a foreign 
country | Man sprouts wings, flys south for the winter and saves a country ! Man 
sprouts wings and saves a country | Man flys and saves country |4| Flying 
man 1 1999 1 John Filmmaker | 
Fields 20- 25: Names of Stars 

20. Star 1 Last Name (0 to 25 bytes) The last name of the 1st actor. 

21 . Star 1 First Name (0 to 25 bytes) The first (middle) name of the 1st actor. 

• 

22. Star 2 Last Name (0 to 25 bytes) The last name of the 2nd actor. 

23. Star 2 First Name (0 to 25 bytes) The first (middle) name of 2nd actor. 

24. Star 3 Last Name (0 to 25 bytes) The last name of the 3rd actor. 

15 25. Star 3 First Name (0 to 25 bytes) The first (middle) name of 3rd actor. 
Examples of these fields are given in Table LXVH. 

Field Name Field# Sample Data 

Star 1 20 Falls 

Star 1 21 Joe 

20 Star 2 22 Floats 

Star 2 23 Mary 

Star 3 24 Soars 

Star 3 25 Sam 

Table LXVII 

25 A sample fragment of the above Show list record fields is as follows: 

Falls | Joe | Floats | Mary | Soars j Sam | 
Genre Byte Fields: Fields 26 - 49 

The Genre Byte Fields are divided into 3 categories. The first is the THEME 
category and it provides for the general description of the show type. StarSight uses 
30 this theme information to divide the programs into discrete categories when theme 
searches are done. The second category is the MPAA rating and is used to inform 
the viewer of the movie industries rating of appropriate age of the viewer for this 



( 
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show. This rating is usually only valid for movies. The third category further 
explains the MPAA rating. 

The following 24 data fields are the explanation of the program theme type. 
A maximum of 5 of these 24 fields are set as TP for any 1 program. Some are 
5 mutually exclusive and will not be set to T' in unison at any time. 





Field # 




26. 


Action 




27. 


Adventure 




28. 


Bioirranhv 


1 A 
1U 


29. 


Classic 




30. 


Comedy 




31. 


Dance 




32. 


Docudram a 




33. 


Documents rv 


1 c 
ID 


34. 


Drama 




35. 


Fantasv 




36. 


Historical 




37. 


Horror 




38. 


Martial Art<: 


on 


39 






40. 


Mystery 




41. 


Opera 




42. 


Romance 




43. 


Satire 


25 


44. 


Science 




45. 


Science Fiction 




46. 


Suspense 




47. 


Thriller 




48. 


Western 


30 


49. 


Situation Comedy 



An example of a record fragment involving the fields above is given in Table 
LXVHI: 
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10 



15 



20 



25 



30 



Field Name 


Field* 


Action 


26 


T 


Adventure 


27 


T 


Biography 


28 


F 


Classic 


29 


F 


Comedy 


30 


T 


Dance 


31 


F 


Docudrama 


32 


F 


Documentary 


33 


F 


Drama 


34 


F 


Fantasy 


35 


T 


Historical 


36 


F 


Horror 


37 


F 


Martial Arts 

****** i*ui * *& uj 


38 


F 


Musical 


39 


F 


Mystery 


40 


F 


Opera 


41 


F 


Romance 


42 


F 


Satire 


43 


T 


Science 


44 


F 


Science Fictinn 


45 


T 


Suspense 


46 


T 


Thriller 


47 


F 


Western 


48 


F 


Situation Comedy 


49 


F 



148 
Sample Data 



Table LXVTTf 

A sample fragment of the above Show list record fields is as follows:. 

T|T|F|F|T|F|F|F|F|T|F|F|F|FJF|F|F|T|F|T|T|F|F|F[ 
MPAA rating: fields 50 - 56 

, Field* 

50. G (1 byte) General audience 

51. NCI7 (1 byte) No children under 17. 

52. NR (1 byte) Not rated. 
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53. PG (1 byte) Parental guidance. 

54. PG13 (1 byte) Parental guidance under 13 years. 

55. R (1 byte) Restricted. 

56. AO (1 byte) Adult Only. Most severe rating. 
Examples of these fields are given in Table LXK. 

Sample Data 



10 



Field Name 


Field# 




G 


50 


T 


NC17 


51 


F 


NR 


52 


F 


PG 


53 


F 


PG13 


54 


F 


R 


55 


F 


AO 


56 


F 



Table LXK 

15 A sample fragment of fields 50 - 56 is as follows: 

T|F|F|F|F|F|F| 
MPAA explanation: Fields 57 - 62. 
Field # 

57. Profanity (1 byte) 
20 58. Nudity (1 byte) 

59. Violence (1 byte) 

60. Adult Situations (1 byte) 

61. Adult Themes (1 byte) 

62. Adult Language (1 byte) 

25 

63. PPV Event: Field 63. 

(1 byte) set to T to indicate this show is a Pay-per-View Event, 'F' if not, 
empty if not known. 

Examples of these fields are given in Table LXX . 
30 Field Name Field* Sample Data 

Profanity 57 % T 

Nudity 58 F 

Violence 59 T 
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Adult Situations 60 F 
Adult Themes 61 T 

Adult Language 62 T 
PPV Event 63 T 

Table LXX 

A record fragment for fields 57-63 is as follows: 
T|F|T|F|T|T|T| 

Fields 64 and Above: Vendor-Defined Fields 

All fields following the 'PPV Event' field are optional (except the mandatory 
End of Record terminator). No minimum or maximum number-of these fields is 
prescribed, and no particular limit is enforced as to the number of characters in any 
one of these fields. 

Vendor may use this portion of the record to provide additonal data related to 
the show which the prescribed format might make difficult or impossible to convey. 
Each Vendor-defined field should be used to describe one data element. 

Field content is free-format, with the previously-stated constraint that all data 
must be transferred as printable ASCII text, with no Vertical Bar(hex 7C), Carriage 
Return (hex 0D), or Linefeed (hex OA) occurring as data, since these characters have 
the special meanings of "Field Delimiter- (Vertical Bar) and "End-of-Record" 
(Carriage Return and/or Linefeed), respectively. 

The intention is to allow the vendor as free a hand as possible in describing 
the show. Additional information about show type, genre, category, subcategory, etc. 
can be placed in these fields, and also other types of information which may not be 
currently anticipated. If these fields are used, vendor must separately provide 
StarSight with a document which defines as fully as possible how these fields are 
used by the vendor. 

The example that follows is not intended to prescribe a set format; it is just 
illustrating one possible way the Vendor Defined Fields could supplement the other 
information in the record. In this example, we will assume the vendor has additional 
categorization available for sports shows, over and above what is prescribed in the 
normal format. The vendor must document the fields separately from the data itself: 
let's say Vendor XYZ has provided StarSight with a document containing the 
following information: 
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Field Name Content or Meaning 
SPNAME Name of sport 
SPENV "Indoor" or "Outdoor" 
SP$ "Professional" , "Amateur", or "Pro-Am" 

5 SPLIVE If present, game is being carried live. 
S PTE AM If present, this is a team sport 

NOTES ON SYNTAX IN VENDOR-DEFINED FIELDS SUPPLIED BY 
VENDOR XYZ: "Field Name" is an unbroken ASCII string (no spaces or tabs 
allowed) from the list above. The presence of the field name in some cases implies a 
10 "TRUE" status; in other cases a value over and above the field's name is also 

specified. If a value is being specified, the field name is followed by a single space 
or tab, and everything else in the field comprises its value. 

Given this information, Vendor XYZ could now transmit StarSight a record 
with Vendor-Defined fields that look like the example below: 
15 First Vendor Defined Field 64 SPNAME Field Hockey 
Second Vendor Defined Field 65 SP$ Professional 
Third Vendor Defined Field 66 SPENV Outdoor 
Fourth Vendor Defined Field 67 SPTEAM 

Fifth Vendor Defined Field 68 SPLIVE 
20 Note that even though SPENV, for example, is specified in field #66 in this 

record, it could be specified in any Vendor-Defined field, or not mentioned at all. 
The same observation applies to all the Vendor-Specified fields. This is true because 
of the method used in this example of giving the name of the field as data. 
If the vendor chose to stick to a more rigid convention, in which every field is 
25 always present whether there is data for that field or not, the name or usage of each 
field could be entirely position-dependent, and could be documented separately, thus 
eliminating the need to transmit field names with the data; either method is 
acceptable, and if the Vendor has another method they prefer, this would probably 
be acceptable too, so long as it stays within the rules stated earlier. 
30 A sample fragment of the above Show list record fields is as follows: 

SPNAME Field Hockey | SP$ Professional | SPENV 
Outdoor | SPTEAM | SPLIVE | 

End Of Record (LINEFEED hex OA) and/or (CARRIAGE RETURN hexOD) 
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Marks the end of a record. Flexibility of definition is to allow for the transfer 
of text between different types of computer systems. 
End Of File Record 

Following the final data record in a file, the Vendor must append a special 
5 End-of-File record, which is defined to be a record that begins with the text string 
"ZZZZZEOF", followed (possibly with intervening Vendor-Defined fields) by End 
of Record. StarSight's software will encounter this text string when it is expecting to - 
read a Call Sign value; the value read will be tested against this reserved value, and 
if they match, StarSight's software will halt reading of the file. 

10 More importantly, this text string will also be used to test for completion of a 

file transfer. If a new file appears in the data input directory, the input software will 
examine the final record of the file for this symbol; if the symbol is not found, then 
the data transfer has either aborted in midstream, or has not yet completed; in either 
case, it would not yet be appropriate to begin loading the data. 

15 Note that the definition of this record is that it begins with ZZZZZEOF and 

ends with End of Record; the remainder of the record may defined by the Vendor, 
within the usual constraints for Vendor-Defined fields. Supplemental information that 
would be useful here might include a count of the number of records in the file, the 
date/time of production, a list of stations with which problems occurred, or any other 

20 summary information the vendor considers relevant. 
SPECIAL NOTE(s): 

The format of the Show list records that are used in building the StarSight 
electronic database are highly integrated into our database program and these formats 
must not be altered or changed in any way without the written consent of StarSight 

25 Telecast. Use of the Vendor-Defined Fields is allowed, provided the syntax and 
meanings of the fields used are clearly documented in advance of use. 
Since the PO names used within the Show list file are referenced by the StarSight 
database application, the PO names must be unique and remain constant. The 
changing of any PO name without proper coordination with StarSight will cause a 

30 mismatch of data in the StarSight database. 

It should now be readily apparent to those skilled in the art that a novel 
television schedule information transmission system amd method capable of achieving 
the stated objects of the invention has been provided. The system and method can be 
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implemented with low cost microprocessors and memory in subscriber data 
processing systems, in the system and method, television program schedule data is 
transmitted and stored in a manner that allows a low cost microprocessor suitable for 
use in a mass produced consumer product to carry out subset searching of the 
television program schedule data. Television program schedule information is 
transmitted to and acquired by the subscriber data processing systems in an efficient 
manner in the system and method. Fast schedule updates to accommodate schedule . 
changes can be provided with a low bandwidth transmission system and method. 
The system and method is able to distinguish between currently broadcast schedule 
information and older schedule information included with a broadcast that was 
recorded. The system and method gives schedule update information priority 
treatment. The schedule information transmission is selectively encrypted in the 
system and method. A single system time is employed in schedule information 
transmission portions of the system and method and compensation for local time is 
carried out in the subscriber units. In the system and method, the subscriber units 
are able to identify schedule information provided in different locations of a 
television broadcast signal. Portions of schedule information already acquired by a 
subscriber unit and which duplicate portions of new schedule information are 
retained in the system and method, so that such schedule information portions need 
not be acquired again by the subscriber unit. Data compression is employed in a 
unique way to make most efficient use of available memory in the system and 
method. 

It should further be apparent to those skilled in the art that various changes in 
form and details of the invention as shown and described may be made. It is 
intended that such changes be included within the spirit and scope of the claims 
appended hereto. 



WO 95/31069 PCT/US95/05169 

154 

WHAT IS CLAIMED IS: 

1. A television schedule information transmission system, which comprises a 
central data processing system, means connected to said central data processing 
system for providing schedule information data for a predetermined territory to said 
5 central data processing system, said central data processing system including means 
for formatting the schedule information data for the predetermined territory into a 
predetermined schedule information transmission format, means coupled to said 
central data processing system for transmitting the schedule information data for the 
predetermined territory in the predetermined schedule information transmission 

10 formats, a plurality of regional data processing systems, each located in a region of 
the predetermined territory, said plurality of regional data processing systems each 
including means for receiving the schedule information data for the predetermined 
territory, means for selecting the schedule information data for the region in which 
each of said plurality of regional data processing systems is located and means for 

IS transmitting the schedule information data for the region, and a plurality of 

subscriber data processing systems in each of the regions, each of said plurality of 
subscriber data processing systems including means for receiving at least a portion of 
the schedule information data for the region, means for storing the schedule 
information data received by the subscriber data processing system, means for 

20 assembling portions of the schedule information data received by the subscriber data 
processing system for display to a user of the subscriber data processing system and 
a display connected to said means for assembling portions of the schedule 
information data to display the portions of the schedule information data. 

25 2. The television schedule information transmission system of claim 1 in 

which said system additionally includes at least one intermediate data processing 
system between at least one of said plurality of regional data processing systems and 
a portion of the plurality of subscriber data processing systems in a region in which 
said at least one of said plurality of regional data processing systems is located, said 

30 intermediate data processing system including means for receiving the schedule 

information data for the region, means for selecting schedule information data for the 
portion of the plurality of subsriber data processing systems in the region from die 
schedule information data for the region and means for transmitting the schedule 
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information data for the portion of the plurality of of subscriber data processing 
systems in the region, said means for transmitting being coupled to the portion of the 
plurality of subscriber data processing systems. 

5 3. The television schedule information transmission system of claim 2 in 

which said at least one intermediate data processing system is a cable operator data 
processing system. 

4. The television schedule information transmission system of claim 1 in 
10 which the schedule information data is transmitted in the form of commands, the 

commands including instructions for the plurality of subscriber data processing 
systems in each region and television schedule information used by the commands to 
assemble portions of the television schedule information to display the portions of the 
schedule information data. 

15 

5. The television schedule information transmission system of claim 4 in 
which the schedule information commands for the predetermined territory include 
region commands each identifying channels which are available in one of the regions 
in the territory and a region identification, each of said regional data processing 

20 Systems having a region identification for comparing with the region identification of 
each region command to recognize region commands intended for that regional data 
processing system. 

6. The television schedule information transmission system of claim 1 in 
25 which said plurality of subscriber data processing systems in each of the regions 

includes a means for determining if certain of the television schedule information in 
the commands has already been acquired by the subscriber data processing system, 
and in which the certain of the television schedule information is acquired if it has 
not already been acquired. 

30 

7. The television schedule information transmission system of claim 6 in 
which the certain of the television schedule information includes show titles. 
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8. The television schedule information transmission system of claim 7 in 
which the show titles include character strings that have previously been acquired. 

9. The television schedule information transmission system of claim 6 in 
5 which the certain of the television schedule information includes missing data for 

future time periods. 

10. The television schedule information transmission system of claim 1 in 
i which each of said plurality of subscriber data processing systems in each of the 

10 regions includes a memory for storing database items comprising the television 

schedule information, each of the database items having a handle as an index into a 
handle table identifying memory locations corresponding to the handle. 

11. In a television schedule information transmission system including a 
15 central data processing system for a predetermined territory having means for 

transmitting television schedule data for the predetermined territory and subscriber 
data processing systems in the predetermined territory, the improvement which 
comprises a plurality of regional data processing systems, each located in a region of 
the predetermined territory, said plurality of regional data processing systems each 
20 including means for receiving the schedule information data for the predetermined 
territory, means for selecting the schedule information data for the region in which 
each of said plurality of regional data processing systems is located and means for 
transmitting the schedule information data for the region to a plurality of said 
subscriber data processing systems in each of the regions. 

25 

12. The television schedule information transmission system of claim 11 in 
which each of said plurality of subscriber data processing systems includes means for 
receiving at least a portion of the schedule information data for the region, means for 
storing the schedule information data received by the subscriber data processing 

30 system, means for assembling portions of the schedule information data received by 
the subscriber data processing system for display to a user of the the subscriber data 
processing system and a display connected to said means for assembling portions of 
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the schedule information data to display the portions of the schedule information 
data. 

13. The television schedule information transmission system of claim 11 in 
5 which said system additionally includes at least one intermediate data processing 

system between at least one of said plurality of regional data processing systems and 
a portion of the plurality of subscriber data processing systems in a region in which . 
said at least one of said plurality of regional data processing systems is located, said 
intermediate data processing system including means for receiving the schedule 

10 information data for the region, means for selecting schedule information data for the 
portion of die plurality of subscriber data processing systems in the region from the 
schedule information data for the region and means for transmitting the schedule 
information data for the portion of the plurality of of subscriber data processing 
systems in the region, said means for transmitting being coupled to the portion of the 

15 plurality of subscriber data processing systems. 

14. The television schedule information transmission system of claim 13 in 
which said at least one intermediate data processing system is a cable operator data 
processing system. 

20 

15. The television schedule information transmission system of claim 11 in 
which the schedule information data is transmitted in the form of commands, the 
commands including instructions for the plurality of subscriber data processing 
systems in each region and television schedule information used by the commands to 

25 assemble portions of the television schedule information to display the portions of the 
schedule information data. 

16. The television schedule information transmission system of claim 15 in 
which the schedule information commands for the predetermined territory include 

30 region commands each identifying channels which are available in one of the regions 
in the territory and a region identification, each of said regional data processing 
systems having a region identification for comparing with the region identification of 
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each region command to recognize region commands intended for that regional data 
processing system. 



17. The television schedule information transmission system of claim 11 in 
which said plurality of subscriber data processing systems in each of the regions 
includes a means for determining if certain of the television schedule information in 
the commands has already been acquired by the subscriber data processing system, 
and in which the certain of the television schedule information is acquired if it has 
not already been acquired. 

18. The television schedule information transmission system of claim 17 in 
which the certain of the television schedule information includes show titles. 

19. The television schedule information transmission system of claim 18 in 
which the show titles include character strings that have previously been acquired. 

20. The television schedule information transmission system of claim 17 in 
which the certain of the television schedule information includes missing data for 
future time periods. 

21 . The television schedule information transmission system of claim 1 1 in 
which each of said plurality of subscriber data processing systems in each of the 
regions includes a memory for storing database items comprising the television 
schedule information, each of the database items having a handle as an index into a 
handle table identifying memory locations corresponding to the handle. 

22. The television schedule transmission system of claim 1 1 in which said 
means for transmitting the schedule information data for the region in each of said 
plurality of regional data processing systems has an ability to transmit the schedule 
information data for the region in different places of a television broadcast signal and 
each of said subscriber data processing systems includes a means for locating the 
schedule information data in the television broadcast signal. 
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23. The television schedule transmission system of claim 22 in which the 
different places in the television broadcast signal comprise different lines of a vertical 
blanking interval. 

5 24. In a television schedule information transmission system, the method 

which comprises transmitting schedule information data for a predetermined territory 
to a plurality of regional data processing systems each located in a region of the 
territory, selecting the schedule information data for each region with its regional 
data processing system, transmitting the schedule information data for each region 
10 with its regional data processing system to a plurality of subscriber data processing 
systems in each region, assembling portions of the schedule information data 
received by each subscriber data processing system for display to a user of each 
subscriber data processing system, and displaying the portions of the schedule 
information data to the user. 

15 

25. The method of claim 24 additionally comprising the steps of transmitting 
the schedule information for at least one the regions to at least one intermediate data 
processing system between at least one of the plurality of regional data processing 
systems and a portion of the plurality of subscriber data processing systems in a 

20 region in which the at least one of the plurality of regional data processing systems is 
located, and transmitting the schedule information data for the portion of the plurality 
pf subscriber data processing systems in the region from the intermediate data 
processing system to the portion of the plurality of subscriber data processing 
systems. 

25 

26. The method of claim 25 in which the schedule information data is 
transmitted in the form of commands, the commands including instructions for the 
plurality of subscriber data processing systems in each region and television schedule 
information used by the commands to assemble portions of the television schedule 

30 information to display the portions of the schedule information data. 

27. The method of claim 26 in which the schedule information commands 
for the predetermined territory include region commands each identifying channels 
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which are available in one of the regions in the territory and a region identification, 
each of the regional data processing systems comparing a stored region identification 
with the region identification of each region command to recognize region commands 
intended for that regional data processing system. 

5 

28. The method of claim 24 in which each of the plurality of subscriber data 
processing systems determines if certain of the television schedule information in the . 
commands has already been acquired by the subscriber data processing system, and 
acquires the certain of the television schedule information if it has not already been 

10 acquired. 

29. The method of claim 24 in which at least some of the plurality of 
regional data processing systems transmit the schedule information data in different 
places of a television broadcast signal and each of the plurality of subscriber data 

15 processing systems locates the schedule information data in the television broadcast 
signal. 



30. The method of claim 29 in which the different places in the television 
broadcast signal comprise different lines of a vertical blanking interval. 

20 

31. In a television schedule information transmission system including a 
central data processing system for a predetermined territory having means for 
transmitting television schedule data for the predetermined territory and a plurality of 
subscriber data processing systems in the predetermined territory, the improvement 

25 which comprises means in said central data processing system for transmitting the 
television schedule data as commands, the commands including instructions for said 
plurality of subscriber data processing systems in said system and television schedule 
information used by the commands in said plurality of subscriber data processing 
systems to assemble and display a television schedule. 

30 

32. The television schedule information transmission system of claim 31 in 
which each of said plurality of subscriber data processing systems includes a means 
for determining if certain of the television schedule information in the commands has 
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already been acquired by the subscriber data processing system, and in which the 
certain of the television schedule information is acquired if it has not already been 
acquired. 

33. The television schedule information transmission system of claim 32 in 
which the certain of the television schedule information includes show titles. 

34. The television schedule information transmission system of claim 33 in 
which the show titles include character strings that have previously been acquired. 

35. The television schedule information transmission system of claim 32 in 
which the certain of the television schedule information includes missing data for 
future time periods. 

36. The television schedule information transmission system of claim 31 in 
which said system additionally includes a plurality of regional data processing 
systems, each located in a region of the predetermined territory, said plurality of 
regional data processing systems each including means for receiving the schedule 
information data for the predetermined territory, means for selecting the schedule 
information data for the region in which each of said plurality of regional data 
processing systems is located and means for transmitting the schedule information 
data for the region to a portion of said plurality of said subscriber data processing 
systems in each of the regions. 

37. The television schedule information transmission system of claim 36 in 
which said system additionally includes at least one intermediate data processing 
system between at least one of said plurality of regional data processing systems and 
some of the portion of said plurality of subscriber data processing systems in a 
region in which said at least one of said plurality of regional data processing systems 
is located, said intermediate data processing system including means for receiving the 
schedule information data for the region, means for selecting schedule information 
data for the some of the portion of the plurality of subscriber data processing systems 
in the region from the schedule information data for the region and means for 
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transmitting the schedule information data for the some of the portion of the plurality 
of subscriber data processing systems in the region, said means for transmitting 
being coupled to the some of the portion of the plurality of subscriber data 
processing systems. 

38. The television schedule information transmission system of claim 37 in 
which said at least one intermediate data processing system is a cable operator data • 
processing system. 

39. The television schedule information transmission system of claim 31 in 
which each of said plurality of subscriber data processing systems in each of the 
regions includes a memory for storing database items comprising the television 
schedule information, each of the database items having a handle as an index into a 
handle table identifying memory locations corresponding to the handle. 

40. In a television schedule information transmission system, the method 
which comprises transmitting commands from a central data processing system to a 
plurality of subscriber data processing systems, the commands including instructions 
for the plurality of subscriber data processing systems in said system and television 
schedule information used by the commands in the plurality of subscriber data 
processing systems to assemble and display a television schedule, assembling the 
television schedule from the television schedule information in each of the plurality 
of subscriber data processing systems, and displaying the television schedule to a 
user of each of the plurality of subscriber data processing systems. 

41 . The method of claim 40 in which each of the plurality of subscriber data 
processing systems determines if certain of the television schedule information in the 
commands has already been acquired by the subscriber data processing system, and 
acquires the certain of the television schedule information if it has not already been 

30 acquired. 

42. The method of claim 40 additionally comprising the steps of transmitting 
schedule information data for a predetermined territory to a plurality of regional data 
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processing systems each located in a region of the territory, selecting the schedule 
information data for each region with its regional data processing system, and 
transmitting the schedule information data for each region with its regional data 
processing system to a plurality of subscriber data processing systems in each region. 

5 

43. The method of claim 42 additionally comprising the steps of transmitting 
the schedule information for at least one the regions to at least one intermediate data • 
processing system between at least one of the plurality of regional data processing 
systems and a portion of the plurality of subscriber data processing systems in a 

10 region in which the at least one of the plurality of regional data processing systems is 
located, and transmitting the schedule information data for the portion of the plurality 
of subscriber data processing systems in the region from the intermediate data 
processing system to the portion of the plurality of subscriber data processing 
systems. 

15 

44. The method of claim 42 in which the schedule information commands 
for the predetermined territory include region commands each identifying channels 
which are available in one of the regions in the territory and a region identification, 
each of the regional data processing systems comparing a stored region identification 

20 with the region identification of each region command to recognize region commands 
intended for that regional data processing system. 

45. In a television schedule information transmission system including a 
central data processing system for a predetermined territory having means for 

25 transmitting television schedule data for the predetermined territory and a plurality of 
subscriber data processing systems in the predetermined territory, the improvement 
which comprises means in said central data processing system for transmitting a 
predetermined character string comprising a portion of the schedule information to 
said plurality of subscriber data processing systems, means in each of said plurality 

30 of subscriber data processing systems for determining whether the predetermined 
character string has been acquired by that subscriber data processing system, and 
means in each of said plurality of subscriber data processing systems for storing the 
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predetermined character string in that subscriber data processing system if it has not 
already been acquired. 

46. The television schedule information transmission system of claim 45 in 
which the certain of the television schedule information includes show titles. 

47. The television schedule information transmission system of claim 45 in • 
which the certain of the television schedule information includes missing data for 
future time periods. 

» 

48. The television schedule information transmission system of claim 45 in 
which each of said plurality of subscriber data processing systems includes a memory 
for storing database items comprising the television schedule information, each of the 
database items having a handle as an index into a handle table identifying memory 
locations corresponding to the handle. 

49. The television schedule information transmission system of claim 45 in 
which said system additionally includes a plurality of regional data processing 
systems, each located in a region of the predetermined territory, said plurality of 
regional data processing systems each including means for receiving the schedule 
information data for the predetermined territory, means for selecting the schedule 
information data for the region in which each of said plurality of regional data 
processing systems is located and means for transmitting the schedule information 
data for the region to a portion of said plurality of said subscriber data processing 
systems in each of the regions. 

50. The television schedule information transmission system of claim 49 in 
which said system additionally includes at least one intermediate data processing 
system between at least one of said plurality of regional data processing systems and 
some of the portion of said plurality of subscriber data processing systems in a 
region in which said at least one of said plurality of regional data processing systems 
is located, said intermediate data processing system including means for receiving the 
schedule information data for the region, means for selecting schedule information 
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data for the some of the portion of the plurality of subscriber data processing systems 
in the region from the schedule information data for the region and means for 
transmitting the schedule information data for the some of the portion of the plurality 
of subscriber data processing systems in the region, said means for transmitting 
5 being coupled to the some of the portion of the plurality of subscriber data 
processing systems. 

51. The television schedule information transmission system of claim 50 in 
which said at least one intermediate data processing system is a cable operator data 

10 processing system. 

52. In a television schedule information transmission system, the method 
which comprises transmitting a predetermined character string comprising a portion 
of the schedule information to a plurality of subscriber data processing systems in 

15 said system, determining in each of the plurality of subscriber data processing 
systems whether the predetermined character string has been acquired by that 
subscriber data processing system, and storing the predetermined character string in 
that subscriber data processing system if it has not already been acquired. 

20 53. The method of claim 52 additionally comprising the steps of transmitting 

schedule information data for a predetermined territory to a plurality of regional data 
processing systems each located in a region of the territory, selecting the schedule 
information data for each region with its regional data processing system, and 
transmitting the schedule information data for each region with its regional data 

25 processing system to a plurality of subscriber data processing systems in each region. 

54. The method of claim 53 additionally comprising the steps of transmitting 
the schedule information for at least one the regions to at least one intermediate data 
processing system between at least one of the plurality of regional data processing 
30 systems and a portion of the plurality of subscriber data processing systems in a 

region in which the at least one of the plurality of regional data processing systems is 
located, and transmitting the schedule information data for the portion of the plurality 
of subscriber data processing systems in the region from the intermediate data 
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processing system to the portion of the plurality of subscriber data processing 
systems. 

55. The method of claim 53 in which the schedule information commands 
5 for the predetermined territory include region commands each identifying channels 

which are available in one of the regions in the territory and a region identification, 
each of the regional data processing systems comparing a stored region identification ■ 
with the region identification of each region command to recognize region commands 
intended for that regional data processing system. 

10- 

56. In a television schedule information transmission system including a 

direct broadcast satellite, a central data processing system having means for 

i • 
transmitting television schedule data for the direct broadcast satellite to the direct 

broadcast satellite, and subscriber data processing systems having means for 

15 receiving the television schedule data for the direct broadcast satellite from the direct 

broadcast satellite, the improvement which comprises a plurality of regional data 

processing systems, each located in a region of a predetermined territory, said 

plurality of regional data processing systems each including means for receiving the 

schedule information data for the predetermined territory, means for selecting the 

20 schedule information data for the region in which each of said plurality of regional 

data processing systems is located and means for transmitting the schedule 

information data for the region to a plurality of said subscriber data processing 

systems in each of the regions. 

25 57. The television schedule information transmission system of claim 56 in 

which ^ach of said plurality of subscriber data processing systems includes means for 
receiving at least a portion of the schedule information data for the region from the 
one of said plurality of regional data processing systems for the region, means for 
storing the schedule information data received by the subscriber data processing 

30 system from said direct broadcast satellite and the one of said plurality of regional 
data processing systems, means for assembling portions of the stored schedule 
information data received by the subscriber data processing system for display to a 
user of the the subscriber data processing system and a display connected to said 



WO 95/31069 PCT/US95/05169 

167 

means for assembling portions of the schedule information data to display the 
assembled portions of the schedule information data. 

58. The television schedule information transmission system of claim 56 in 
5 which said system additionally includes at least one intermediate data processing 

system between at least one of said plurality of regional data processing systems and 
a portion of the plurality of subscriber data processing systems in a region in which * 
said at least one of said plurality of regional data processing systems is located, said 
intermediate data processing system including means for receiving the schedule 

10 information data for the region, means for selecting schedule information data for the 
portion of the plurality of subscriber data processing systems in the region from the 
schedule information data for the region and means for transmitting the schedule 
information data for the portion of the plurality of subscriber data processing systems 
in the region, said means for transmitting being coupled to the portion of the 

15 plurality of subscriber data processing systems. 

59. The television schedule information transmission system of claim 58 in 
which said at least one intermediate data processing system is a cable operator data 
processing system. 

20 

60. The television schedule information transmission system of claim 56 in 
which the schedule information data is transmitted in the form of commands, the 
commands including instructions for the plurality of subscriber data processing 
systems in each region and television schedule information used by the commands to 

25 assemble portions of the television schedule information to display the portions of the 
schedule information data. 

61 . The television schedule information transmission system of claim 60 in 
which the schedule information commands for the predetermined territory include 

30 region commands each identifying channels which are available in one of the regions 
in the territory and a region identification, each of said regional data processing 
systems having a region identification for comparing with the region identification of 
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each region command to recognize region commands intended for that regional data 
processing system. 

62. The television schedule information transmission system of claim 56 in 
5 which said plurality of subscriber data processing systems in each of the regions 

includes a means for determining if certain of the television schedule information in 
the commands has already been acquired by the subscriber data processing system, 
and in which the certain of the television schedule information is acquired if it has 
not already been acquired. 

10 

63. The television schedule information transmission system of claim 62 in 
which the certain of the television schedule information includes show titles. 

64. The television schedule information transmission system of claim 63 in 
15 which the show titles include character strings thk have previously been acquired. 

65. The television schedule information transmission system of claim 62 in 
which the certain of the television schedule information includes missing data for 
future time periods. 

20 

66. The television schedule information transmission system of claim 56 in 
which each of said plurality of subscriber data processing systems in each of the 
regions includes a memory for storing database items comprising the television 
schedule information, each of the database items having a handle as an index into a 

25 handle table identifying memory locations corresponding to the handle. 

67. In a television schedule information transmission system, the method 
which comprises transmitting television schedule data for a direct broadcast satellite 
to the direct broadcast satellite, receiving the television schedule data for the direct 

30 broadcast satellite from the direct broadcast satellite at a subscriber data processing 
system, receiving schedule information data for a predetermined territory in a 
regional data processing system located in a region of the predetermined territory, 
selecting the schedule information data for the region in which the regional data 
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processing system is located and transmitting the schedule information data for the 
region to the subscriber data processing system. 

68. The method of claim 67 additionally comprising the steps of receiving at 
5 least a portion of the schedule information data for the region from the regional data 

processing system for the region at the subscriber data processing system, storing the 
schedule information data received by the subscriber data processing system from the- 
direct broadcast satellite and the regional data processing system, assembling portions 
of the stored schedule information data received by the subscriber data processing 
10 system for display to a user of the the subscriber data processing system and 

displaying the assembled portions of the schedule information data. 

■ 

69. The method of claim 68 in which the schedule information data received 
by the subscriber data processing system from the direct broadcast satellite and the 

15 regional data processing system is stored as database items comprising the television 
schedule information, each of the database items having a handle as an index into a 
handle table identifying memory locations corresponding to the handle. 

70. The method of claim 67 additionally comprising the steps of receiving a 
20 portion of the schedule information for the region at an intermediate data processing 

system between the regional data processing system and the subscriber data 
processing system, selecting schedule information data for the subscriber data 
processing system from the schedule information data for the region and transmitting 
the schedule information data for the subscriber data processing system to the 
25 subscriber data processing system. 

71 . The method of claim 67 in which the schedule information data is 
transmitted in the form of commands, the commands including instructions for the 
subscriber data processing system and television schedule information used by the 

30 commands to assemble portions of the television schedule information to display the 
portions of the schedule information data. 
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72. The method of claim 71 in which the schedule information commands 
include a region command identifying channels which are available in the region and 
a region identification, the regional data processing system having a region 
identification for comparing with the region identification of the region command to 
5 recognize the region command intended for the regional data processing system. 



73. The method of claim 71 additionally comprising the steps of determining • 
if certain of the television schedule information in the commands has already been 
acquired by the subscriber data processing system, and acquiring the certain of the 

10 television schedule information if it has not already been acquired. 

74. In a television schedule information transmission system including a 
central data processing system having means for transmitting television schedule 
data, and a subscriber data processing system having means for receiving at least 

15 some of the television schedule data transmitted by said central data processing 
system, the improvement which comprises said subscriber data processing system 
including a memory for storing database items comprising the television schedule 
information, each of the database items having a handle as an index into a handle 
table identifying memory locations corresponding to the handle. 

75. In a television schedule information transmission system, the method 
which comprises transmitting television schedule data, receiving at least some of the 
television schedule data at a subscriber data processing system as database items 
comprising the television schedule information, each of the database items having a 
handle, and using the handle as an index into a handle table identifying memory 
locations corresponding to the handle. 

76. In a television schedule information transmission system including a 
central data processing system for a predetermined territory having means for 
transmitting television schedule data for the predetermined territory and a plurality of 
subscriber data processing systems in the predetermined territory, each of said 
plurality of subscriber data processing systems including a receiver for television 
schedule data, a memory for storing television schedule data, said memory being 
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coupled to said receiver, the improvement which comprises said means for 
transmitting television schedule data being configured to transmit the television 
schedule data (specify what is special about how the data is transmitted that facilitates 
subset searching), each of said plurality of subscriber units including a memory 
controller between said receiver and said memory, said memory controller being 
configured to store television schedule data (specify what is special about the way the 
information is stored that facilitates subset searching). 



77. In a television schedule information transmission system including a 
central data processing system for a predetermined territory having means for 
transmitting television schedule data for the predetermined territory including updates 
of television schedule data previously transmitted and a plurality of subscriber data 
processing systems in the predetermined territory, each of said plurality of subscriber 
data processing systems including a receiver for television schedule data, a memory 
for storing television schedule data, said memory being coupled to said receiver, the 
improvement which comprises means in said central data processing system for 
assigning a transmission priority for the updates of television schedule data 
previously transmitted relative to other television schedule data. 

78. The television schedule information transmission system of claim 77 in 
which said means for assigning a transmission priority for the updates includes 
means for assigning relative transmission priority among the updates. 

79. The television schedule information transmission system of claim 78 in 
which the means for assigning relative transmission priority among the updates 
assigns the relative transmission priority among the updates using update file names. 

80. In a television schedule information transmission system, the method 
which comprises establishing a relative priority for transmission of the television 
schedule information between updates of originally transmitted television schedule 
information and originally transmitted schedule information, transmitting the 
television schedule information in accordance with the relative priority and receiving 
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at least some of the transmitted television schedule information at a subscriber data 
processing system. 

81 . The method of claim 80 additionally comprising the steps of assigning 
5 relative priority for transmission among the updates of originally transmitted 

television schedule information, and transmitting the updates of originally transmitted 
television schedule information in accordance with the relative priority of the 
updates. 

0 82. The method of claim 80 in which the relative priorities between updates 
and originally transmitted television schedule information are established by using 
file names. 

83. In a television schedule information transmission system including a 
5 central data processing system for a predetermined territory having means for 

transmitting television schedule data for the predetermined territory and a plurality of 
subscriber data processing systems in the predetermined territory, each of said 
plurality of subscriber data processing systems including a receiver for television 
schedule data, a memory for storing television schedule data, said memory being 

) coupled to said receiver, the improvement which comprises means in said central 
data processing system for identifying the transmitted television schedule data by 
time relative to other transmitted television schedule data and means in said 
subscriber data processing system for determining if television schedule data received 
by said subscriber data processing system has a time identification later than a time 

> identification of television schedule data stored in said memory. 

84. The television schedule information transmission system of claim 83 in 
which said system includes a recording device coupled to said subscriber data 
processing system, the television schedule data being broadcast in a television 

1 broadcast signal, said recording device including the television schedule data in a 
recording of the television broadcast signal. 



WO 95/31069 PCTVUS95/05169 

173 

85. The television schedule information transmission system of claim 83 in 
which said means for identifying the transmitted television schedule data by time 
relative to other transmitted television schedule data identifies the transmitted 
television schedule data by time through a time tag transmitted with the television 

5 schedule data. 

86. In a television schedule information transmission system, the method 
which comprises transmitting television schedule data with an identification of the 
transmitted television schedule data by time relative to other transmitted television 

10 schedule data, receiving the transmitted television schedule data with a subscriber 
data processing system, storing the television schedule data in a memory of the 
subscriber data processing system, subsequently supplying television schedule data 
including an identification by time relative to other television schedule data, 
comparing the identification by time of the subsequently supplied television schedule 

15 data with the identification by time of the television schedule data stored in the 

memory, replacing the stored television schedule data with the subsequently supplied 
television schedule data if the identification by time of the subsequently supplied 
television schedule data is later than the identification by time of the stored television 
schedule data, and maintaining the stored television schedule data in the memory if 

20 the identification by time of the stored television schedule data is later than the 
identification by time of the subsequently supplied television schedule data. 

87. The method of claim 86 in which the subsequently supplied television 
schedule data is supplied by transmission. 

25 

88. The method of claim 86 in which the television schedule data is supplied 
by a recording device. 

89. In a television schedule information transmission system including a 
30 central data processing system for a predetermined territory having means for 

transmitting television schedule data for the predetermined territory and a plurality of 
subscriber data processing systems in the predetermined territory, each of said 
plurality of subscriber data processing systems including a receiver for television 
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schedule data, a memory for storing television schedule data, said memory being 
coupled to said receiver, the improvement which comprises means in said central 
data processing system for encrypting a selected portion of the television schedule 
data required by said subscriber data processing system to assemble a television 
5 schedule for display and means in said subscriber data processing system for 
decrypting the selected portion of the television schedule data. 

90. The television schedule information transmission system of claim 89 in 
which said means for encrypting is configured to encrypt a show list portion of the 

10 television schedule data. 

91 . In a television schedule information transmission system, the method 
which comprises selectively encrypting a portion of television schedule data 
necessary to assemble a television schedule for display, transmitting the television 

15 schedule data including the encrypted portion, receiving the television schedule data 
in a subscriber data processing system, decrypting the encrypted portion of the 
television schedule data, and using the television schedule data, including the 
portion, to assemble a television schedule for display. 

20 92. The method of claim 91 in which the encrypted portion of the television 

schedule data comprises a show list. 

93. In a television schedule information transmission system including a 
central data processing system for a predetermined territory having means for 

25 transmitting television schedule data for the predetermined territory and a plurality of 
subscriber data processing systems in the predetermined territory, each of said 
plurality of subscriber data processing systems including a receiver for television 
schedule data, a memory for storing television schedule data, said memory being 
coupled to said receiver, the improvement which comprises a real time clock in said 

30 central data processing system for establishing a single system time for said 

transmission system, said means for transmitting television schedule data including 
means for transmitting the single system time, said receiver including means for 
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receiving the single system time, said memory having a stored value for calculating 
local real time from the single system time. 

94. The television schedule information transmission system of claim 93 in 

5 which said means for transmitting television schedule data further includes means for 
transmitting the value for calculating local real time from the single system time to 
said subscriber data processing system. 

95. In a television schedule information transmission system, the method 
10 which comprises establishing a single system time related to real time, transmitting 

the single system time to a subscriber data processing system, transmitting television 
schedule data expressed in the single system time to the subscriber data processing 
system, providing a value to the subscriber data processing system for calculating 
local real time from the single system time, and calculating local times for a 
15 television schedule from the schedule data expressed in the single system time using 
the value. 

96. The method of claim 95 in which the value is provided to the subscriber 
data processing system by transmission in the television schedule information 

20 transmission system. 

97. In a television schedule information transmission system including a 
central data processing system for a predetermined territory having means for 
transmitting television schedule data for the predetermined territory and a plurality of 

25 subscriber data processing systems in the predetermined territory, each of said 
plurality of subscriber data processing systems including a receiver for television 
schedule data, a memory for storing television schedule data, said memory being 
coupled to said receiver, the improvement which comprises said means for 
transmitting television schedule data being configured to transmit the television 

30 schedule data as a show list for each day in the television schedule, said subscriber 
data processing system being configured to maintain show lists for a rolling window 
comprising a plurality of days extending from present time into future time. 
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98. The television schedule transmission system of claim 97 in which the 
show list contains a list of show titles, show descriptions, show start times and show 
durations for a channel. 



5 99. Hie television schedule transmission system of claim 98 in which said 

subscriber data processing system is configured to maintain a count of a number of 
times that character strings in the show lists are used in the rolling window of the 
television schedule and to use the count to retain character strings from the show lists 
for use in additional show lists. 
10 . 

100. In a television schedule information transmission system, the method 
which comprises transmitting television schedule data as a show list for each day in 
the television schedule and maintaining show lists for a rolling window comprising a 
plurality of days extending from present time into future time. 

15 ! 

101. The method of claim 100 in which the show list contains a list of show 
titles, show descriptions, show start times and show durations for a channel. 

102. The method of claim 100 additionally comprising the steps of 
maintaining a count of a number of times thai character strings in the show lists are 
used in the rolling window of the television schedule and to use the count to retain 
character strings from the show lists for use in additional show lists. 

103. In a television schedule information transmission system including a 
central data processing system for a predetermined territory having means for 
transmitting television schedule data for die predetermined territory and a plurality of 
subscriber data processing systems in the predetermined territory, each of said 
plurality of subscriber data processing systems including a receiver for television 
schedule data, a memory for storing television schedule data, said memory being 
coupled to said receiver, the improvement which comprises said subscriber data 
processing systems being configured to store the television schedule data in 
compressed form in said memory, a read only memory in said data processing 
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system for storing fixed text for said system, the fixed text being stored in said read 
only memory in compressed form. 

104. The television schedule transmission system of claim 103 in which the 
5 television schedule data and the fixed text are stored in Huffman encoded form. 

105. In a television schedule information system, the method which 
comprises storing television schedule data in compressed form in a memory of the 
system and storing fixed text for the system in a read only memory in compressed 

10 form. ( 



106. The method of claim 105 in which the television schedule data and the 
fixed text are stored in Huffman encoded form. 
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